Prev: Problem writing quadrature decoder
Next: XmdStub fails when connecting via JTAG.
From: Evan Lavelle on 21 Apr 2008 05:11
Maia is a new tool which automatically creates HDL(*) testbenches from
a vector-style description. The trivial test case below, for example,
is a complete testbench for a 4-bit up-counter with reset.

The tool compiles a test vector file into HDL output, runs the output
and the module sources on a specified simulator, and reports the
results, together with details of any failures. You don't need to know
or write *any* HDL code to use Maia; if you can write vectors for your
module, then you can verify it.

You can download a free compiler and documentation from maia-eda.net.

(*) Apologies to VHDL'ers; 0.8.2 only creates Verilog output. I hope
to have VHDL output before too long.

// ------------------------------------------------------------
// trivial complete testbench example: 4-bit counter with reset
DUT {
module counter(input CLK, RST; output [3:0] Q)
create_clock CLK // define the clock
[CLK, RST] -> [Q] // define the test vector format
}
main() {
[.C, 1] -> [0]; // reset
for(i=1; i <= 16; i++)
[.C, 0] -> [i]; // count, with rollover
}
From: KJ on 21 Apr 2008 11:39
On Apr 21, 5:11 am, Evan Lavelle <nos...(a)nospam.com> wrote:


> You don't need to know
> or write *any* HDL code to use Maia; if you can write vectors for your
> module, then you can verify it.
>

Not to be too much of a slug, but I'm kinda missing the point I think
of this tool....

Why would I want to write test vectors (Hint: I don't). Using a
language with control structures is far more concise and easier to
maintain.

If I did have to write test vectors I would probably use something to
generate those test vectors as an output file artifact from a
simulation run.

> // trivial complete testbench example: 4-bit counter with reset
> DUT {
>   module counter(input CLK, RST; output [3:0] Q)
>   create_clock CLK         // define the clock
>   [CLK, RST] -> [Q]        // define the test vector format}
>
> main() {
>   [.C, 1] -> [0];          // reset
>   for(i=1; i <= 16; i++)
>     [.C, 0] -> [i];        // count, with rollover
>

Having flashbacks to generating test vectors in ABEL...something from
20 years ago.

KJ
From: Mike Treseler on 21 Apr 2008 12:34
> On Apr 21, 5:11 am, Evan Lavelle <nos...(a)nospam.com> wrote:

>> You don't need to know
>> or write *any* HDL code to use Maia; if you can write vectors for your
>> module, then you can verify it.
KJ wrote:

> Not to be too much of a slug, but I'm kinda missing the point I think
> of this tool....

Maybe the intended audience is those
unmotivated to learn vhdl or verilog.
Sort of a testbench 'wizard' to go with
wizard generated code.

Not my cup of tea, but it might get someone started.

-- Mike Treseler
From: HT-Lab on 21 Apr 2008 12:42

"KJ" <kkjennings(a)sbcglobal.net> wrote in message
news:1b5f41df-e273-47c0-b309-460a94735b9e(a)x19g2000prg.googlegroups.com...
On Apr 21, 5:11 am, Evan Lavelle <nos...(a)nospam.com> wrote:


> You don't need to know
> or write *any* HDL code to use Maia; if you can write vectors for your
> module, then you can verify it.
>
>
>Not to be too much of a slug, but I'm kinda missing the point I think
>of this tool....
>
>Why would I want to write test vectors (Hint: I don't). Using a
>language with control structures is far more concise and easier to
>maintain.
>
>If I did have to write test vectors I would probably use something to
>generate those test vectors as an output file artifact from a
>simulation run.

If you look at tools like Mentor's inFact they do exactly that although they
don't create a vector file but an intelligent testbench instead. The inputs
are high-level rules and actions. These high-level rules are compiled into
testbench graphs which are then use to generate optimised vector sets.

For example to test a UART you write different rules for all the different
options like word size, parity type, number of stop bits, interrupt
sequence, read/write sequence etc. The compile will then use this info to
generate an optimised vector set that test all valid combinations (not 100%
sure on this one). I believe this is one step up from writing assertions and
feeding your design with constrained random data.

This is a trivial example but you can understand that with more rules this
becomes more and more powerful. From what I understand these tools are very
complex since they not only need to find the smartest set of testvectors but
also handle all the different constraints and constraint solvers is one area
which is still heavily being researched.

I would say kudos to Evan for attempting to develop a product like this and
making it freely available to the rest of us,

Hans
www.ht-lab.com





> // trivial complete testbench example: 4-bit counter with reset
> DUT {
> module counter(input CLK, RST; output [3:0] Q)
> create_clock CLK // define the clock
> [CLK, RST] -> [Q] // define the test vector format}
>
> main() {
> [.C, 1] -> [0]; // reset
> for(i=1; i <= 16; i++)
> [.C, 0] -> [i]; // count, with rollover
>

Having flashbacks to generating test vectors in ABEL...something from
20 years ago.

KJ


From: KJ on 21 Apr 2008 13:37
On Apr 21, 12:42 pm, "HT-Lab" <han...(a)ht-lab.com> wrote:
> "KJ" <kkjenni...(a)sbcglobal.net> wrote in message
>
> >If I did have to write test vectors I would probably use something to
> >generate those test vectors as an output file artifact from a
> >simulation run.
>
> If you look at tools like Mentor's inFact they do exactly that although they
> don't create a vector file but an intelligent testbench instead. The inputs
> are high-level rules and actions. These high-level rules are compiled into
> testbench graphs which are then use to generate optimised vector sets.
>

There is a huge difference between specifying high level rules and
specifying vectors as the thing that the test creator needs to input.
In fact it's hard to imagine a lower level form of rules than
vectors. As a general rule, most skilled people are likely to be much
more productive working with a higher level of abstraction than with a
lower one.

> For example to test a UART you write different rules for all the different
> options like word size, parity type, number of stop bits, interrupt
> sequence, read/write sequence etc. The compile will then use this info to
> generate an optimised vector set that test all valid combinations (not 100%
> sure on this one). I believe this is one step up from writing assertions and
> feeding your design with constrained random data.
>
> This is a trivial example but you can understand that with more rules this
> becomes more and more powerful. From what I understand these tools are very
> complex since they not only need to find the smartest set of testvectors but
> also handle all the different constraints and constraint solvers is one area
> which is still heavily being researched.
>

Sounds like a pitch for the Mentor stuff, not Evan's.

> I would say kudos to Evan for attempting to develop a product like this and
> making it freely available to the rest of us,
>

I agree, I wasn't trying to disparage the effort, just questioning the
rationale for creating a tool that requires the user to input vector
sets which is a form of test creation popular 20 years ago.

KJ
 |  Next  |  Last
Pages: 1 2
Prev: Problem writing quadrature decoder
Next: XmdStub fails when connecting via JTAG.