Prev: Problem writing quadrature decoder
Next: XmdStub fails when connecting via JTAG.
From: Evan Lavelle on 21 Apr 2008 15:35
On Mon, 21 Apr 2008 09:34:32 -0700, Mike Treseler
<mike_treseler(a)comcast.net> wrote:

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

Could be, but I hope not. I've noticed a couple of interesting things
over the years:

- Most EEs aren't programmers; electronic design and programming are
two completely different things. Verification is programming; the
techniques, tools, and mindset required are different from those
required to do electronic design. And yet, bizzarely, we generally
expect the same people to use the same language to do both things. The
reasons for this are, I think, historical and market-related, and have
nothing to do with the abilities (or otherwise) of Verilog and VHDL.

- Most EEs don't actually verify their code, mainly for the reason
above. I know people who don't verify at all, and others who use
waveform displays. You can get away with this in the FPGA world
because it's fairly simple (if time-consuming) to fix things, and in
the ASIC world because you've got a verification department to find
the problems (or you've actually got your personal verification
engineer assigned to you; I've been there).

Given that lot, the target audience is actually competent EEs who
don't have the time or inclination to start writing complex programs
in an inappropriate language to test their RTL code. Imagine you've
spent a day writing your FSM, or bus interface, or whatever. It gets
to 5 o'clock, and your choice is either (a) to go home and spend the
next day writing a testbench for it, when you've already forgotten
what it does, or (b) spend the next half-hour writing "test vectors"
(yes, bad phrase) for it. I know which one I'd go for.

There's at least one other target audience. If you can read a spec for
someone else's module, then you write vectors for it, even if you know
absolutely no VHDL or Verilog. So, next time your intern's got nothing
to do, you can get them doing something constructive without having to
send them on a training course first.

-Evan
From: Evan Lavelle on 21 Apr 2008 15:38
On Mon, 21 Apr 2008 10:37:52 -0700 (PDT), KJ
<kkjennings(a)sbcglobal.net> wrote:

>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.

I wouldn't get too carried away by the 'test vector' terminology. When
you get down to it, most TBs involve only 3 activities:

1 - generate a set of input data

2 - make sure that the input data gets applied to the DUT at the right
time

3 - wait a bit, check that the output data is as expected, repeat

That's how the RTL works, so it would be difficult to do it any other
way. I call that lot a 'test vector'. It's convenient to put
everything in a "[,,] -> [,,]" format, because it's then obvious
exactly what expressions have to be evaluated and applied to the DUT,
and what exactly the DUT outputs have to be tested against. It's
actually a lot more sophisticated than ABEL - all the inputs and
outputs can be arbitrary expressions, for example, and there are full
C-like control structures, so you get reactive TBs, and all the rest
of it. If you'd prefer, they're not actually "test vectors" - they're
just groups of input and output expressions, but I couldn't think of a
word for that. The great thing (if I do say so myself :)) is that you
have to write absolutely no multi-process code to do this. You don't
need to know any of the TB-related intricacies of VHDL or Verilog to
do this; it's trivial.

It's not a magic bullet, as I say on the website. There are basically
2 reasons that you can't use it for all your everyday verification
needs:

4 - the real smarts in a TB is generating the input data; ie. step 1
above (I'm ignoring here the additional smarts required for coverage
stats collection, temporal assertions, and so on). Currently, your
only options in Maia are essentially table- and algorithm-based. I
should also have file input before too long. I've already done
constrained randomisation for another tool, and that should make its
way in at some point in the future.

5 - There's currently no way to add additional behavioural code to
talk to your DUT (a complex bus interface fronting a memory, for
example). But, again, I've already done this code elsewhere, so it
should make its way in at some point.

-Evan
From: Kevin Neilson on 21 Apr 2008 16:58
KJ wrote:
>
> 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.
>
....
>
> Having flashbacks to generating test vectors in ABEL...something from
> 20 years ago.
>
> KJ

That's a good point. I'm always confused when someone asks me if I have
"test vectors" for a design. No; I have a testbench. The whole
concept of test vectors doesn't even seem to apply for any design with
feedback. I'm having flashbacks to testbenches composed of
simulator-specific "force" commands. -Kevin
From: Evan Lavelle on 22 Apr 2008 06:22
On Mon, 21 Apr 2008 14:58:26 -0600, Kevin Neilson
<kevin_neilson(a)removethiscomcast.net> wrote:

>That's a good point. I'm always confused when someone asks me if I have
> "test vectors" for a design. No; I have a testbench. The whole
>concept of test vectors doesn't even seem to apply for any design with
>feedback. I'm having flashbacks to testbenches composed of
>simulator-specific "force" commands. -Kevin

Different concept. This is not a traditional device "test vector";
it's more of a software "test vector". The phrase "test vector" does
seem to have pressed all the wrong buttons and I've changed it on the
website, and added an explanation on the front page.

In short, these "vectors" may contain arbitrary expressions, and can
be enclosed in standard control constructs (my first posting actually
showed a simple example of both). You can therefore write arbitrary
reactive ("feedback") testbenches; it's nothing like a device test
vector.

However, those are just details. The fundamental idea behind a
"vector" is something different; it's a step up in abstraction levels.
The idea is that you don't have to worry about the details of writing
explicit multi-process timed code; no clock or reset processes, no
reader and checker processes, no driving and sampling, no pass/fail
determination, no error reporting, no process communication, and so
on. It's all wrapped up, automatically, in the "[,,] -> [,,]"
("vector") statement.

As an engineer testing your module, why would you care about any of
that stuff? It's just irrelevant busywork, because Verilog and VHDL
aren't smart enough to handle the details for you. I've expanded all
this on the front page of maia-eda.net, under "what is a vector?".

-Evan

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