testbench techniques

M

mindenpilot

Guest
All,

I'm about to embark on my second large FPGA project.
The first one was a success, with very few bugs.
However, my testbenches were somewhat of a hack.
I simply modeled whatever the UUT was interfacing to, then looked at the
timing diagrams.

I'd like to design more comprehensive tests, and I'm sure there are proper
techniques for this.
For example, I didn't even use any text output.
I'm sure my old approach will work for this new design, but I'd like to
improve.

Part of the problem is that FPGAs are new to our company.
Mine was the first project to use one.
We have no expertise, and I am trying to make sure that our foundation is
solid.

So, if you have expertise, and would like to share what has worked for you,
I would appreciate it.
Or, if you have references that you find useful, that would work, too.

I know there are books about testbenches out there.
But what I'm looking for is a few rules of thumb that are best practices
(kind of like the commandments that were posted here).

Regards,

Adam
 
"mindenpilot" <weissfamily97@charter.net> writes:

So, if you have expertise, and would like to share what has worked for you,
I would appreciate it.
Or, if you have references that you find useful, that would work, too.
Click to expand...
Make everything self-checking, with a result of Pass or Fail. Script
it all. Then run multiple simulations in a regression test, weekly
or even daily.

Most of http://www.joelonsoftware.com/articles/fog0000000043.html
also applies to a good hardware verification environment.

http://verificationguild.com/ is also a good resource.

Cheers,
Colin

--
Your font is: Proportional Monospaced
^
The amazing Font-o-Meter! http://world.std.com/~mmcirvin/
 
Hi Adam,

In addition to all the other suggestions I would advice you to also
investigate the usage of PSL assertions. I know that EDA vendors are
charging an arm and a leg for it but if you can afford it, it will give you
a powerful verification method. If money is an issue than have a look at the
free OVL assertions.
PSL is not difficult and you can probably pick up a useful subset in a day
although if you are serious about it I would suggest one of the excellent
training courses from Doulos/Mentor (and probably many others). Once you
start using assertions then the next step would be to look at functional
verification, very interesting stuff...:)

Hans
www.ht-lab.com


"mindenpilot" <weissfamily97@charter.net> wrote in message
news:uYLaf.1854$Y75.1121@fe06.lga...
All,

I'm about to embark on my second large FPGA project.
The first one was a success, with very few bugs.
However, my testbenches were somewhat of a hack.
I simply modeled whatever the UUT was interfacing to, then looked at the
timing diagrams.

I'd like to design more comprehensive tests, and I'm sure there are proper
techniques for this.
For example, I didn't even use any text output.
I'm sure my old approach will work for this new design, but I'd like to
improve.

Part of the problem is that FPGAs are new to our company.
Mine was the first project to use one.
We have no expertise, and I am trying to make sure that our foundation is
solid.

So, if you have expertise, and would like to share what has worked for
you, I would appreciate it.
Or, if you have references that you find useful, that would work, too.

I know there are books about testbenches out there.
But what I'm looking for is a few rules of thumb that are best practices
(kind of like the commandments that were posted here).

Regards,

Adam
Click to expand...
 
Hans wrote:

In addition to all the other suggestions I would advice you to also
investigate the usage of PSL assertions. I know that EDA vendors are
charging an arm and a leg for it but if you can afford it, it will give you
a powerful verification method. If money is an issue than have a look at the
free OVL assertions.
Click to expand...
This may be the wave of the future,
but I expect Adam will be better
off starting with Testbench 101.

-- Mike Treseler
 
"Mike Treseler" <miketreseler@yahoo.com> wrote in message
news:3t7h45Fquau7U1@individual.net...
Hans wrote:

In addition to all the other suggestions I would advice you to also
investigate the usage of PSL assertions. I know that EDA vendors are
charging an arm and a leg for it but if you can afford it, it will give
you a powerful verification method. If money is an issue than have a look
at the free OVL assertions.

This may be the wave of the future,
but I expect Adam will be better
off starting with Testbench 101.

-- Mike Treseler
Click to expand...

You're probably right, Mike.
But, I do like to see all that is out there.
I checked out your example, and got some good ideas.
Thanks to all for your input.

Regards,

Adam Weiss
 
Adam,

In addition to the other suggestions you got, consider including models
of the components your FPGA interfaces with as part of your verification
environment. The Free Model Foundry (http://www.FreeModelFoundry.com)
offers many models built for just this purpose. And, as the name
implies, they will not cost a thing.

Regards,
Rick


mindenpilot wrote:
All,

I'm about to embark on my second large FPGA project.
The first one was a success, with very few bugs.
However, my testbenches were somewhat of a hack.
I simply modeled whatever the UUT was interfacing to, then looked at the
timing diagrams.

I'd like to design more comprehensive tests, and I'm sure there are proper
techniques for this.
For example, I didn't even use any text output.
I'm sure my old approach will work for this new design, but I'd like to
improve.

Part of the problem is that FPGAs are new to our company.
Mine was the first project to use one.
We have no expertise, and I am trying to make sure that our foundation is
solid.

So, if you have expertise, and would like to share what has worked for you,
I would appreciate it.
Or, if you have references that you find useful, that would work, too.

I know there are books about testbenches out there.
But what I'm looking for is a few rules of thumb that are best practices
(kind of like the commandments that were posted here).

Regards,

Adam
Click to expand...
 
Wow, what a great resource.
Thanks for the input.
Part of my current design includes an SDRAM controller, and I saw a model
for it in there.
That should really help with the testbench.
Thanks for pointing this out!

Regards,

Adam Weiss


"FMF" <fmfoundry@sbcglobal.net> wrote in message
news:4389251A.9060200@sbcglobal.net...
Adam,

In addition to the other suggestions you got, consider including models of
the components your FPGA interfaces with as part of your verification
environment. The Free Model Foundry (http://www.FreeModelFoundry.com)
offers many models built for just this purpose. And, as the name implies,
they will not cost a thing.

Regards,
Rick


mindenpilot wrote:
All,

I'm about to embark on my second large FPGA project.
The first one was a success, with very few bugs.
However, my testbenches were somewhat of a hack.
I simply modeled whatever the UUT was interfacing to, then looked at the
timing diagrams.

I'd like to design more comprehensive tests, and I'm sure there are
proper techniques for this.
For example, I didn't even use any text output.
I'm sure my old approach will work for this new design, but I'd like to
improve.

Part of the problem is that FPGAs are new to our company.
Mine was the first project to use one.
We have no expertise, and I am trying to make sure that our foundation is
solid.

So, if you have expertise, and would like to share what has worked for
you, I would appreciate it.
Or, if you have references that you find useful, that would work, too.

I know there are books about testbenches out there.
But what I'm looking for is a few rules of thumb that are best practices
(kind of like the commandments that were posted here).

Regards,

Adam
Click to expand...
 
mindenpilot wrote:

I'd like to design more comprehensive tests, and I'm sure there are proper
techniques for this.
For example, I didn't even use any text output.
I'm sure my old approach will work for this new design, but I'd like to
improve.
Click to expand...

Have a look at the reference testbench at
http://home.comcast.net/~mike_treseler/
It demonstrates one way to do closed loop verification
and simple text output. Good luck.

-- Mike Treseler
 
On Fri, 4 Nov 2005 08:26:05 -0800, "mindenpilot"
<weissfamily97@charter.net> wrote:

All,

I'm about to embark on my second large FPGA project.
The first one was a success, with very few bugs.
However, my testbenches were somewhat of a hack.
I simply modeled whatever the UUT was interfacing to, then looked at the
timing diagrams.
Click to expand...
You're not alone. It's an excellent way to check a design is
basically functional, and a wonderful way to debug. But as you
have correctly seen, it is a very weak verification technique.

You're asking all the right questions. You will probably find
most of the answers you seek in Janick Bergeron's well-known
book "Writing Testbenches". Basically....
- identify key interfaces on your design
- write bus-functional models, probably in the form of
procedures, to stimulate those interfaces
- similarly, write passive BFMs to capture the transactions
taking place on those interfaces, convert them into record
objects and push those record objects out of the BFM on a
single record port
- checker blocks can pick up those transaction records and
write them to an output file, compare output transactions
with input transactions, measure latency and so on

<shameless advertisement> You could attend our Expert VHDL
Verification class to get a kick-start on this sort of stuff.
</shameless advertisement>
Other classes and textbooks are available...
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top