Seeking advice on FPGA verification methodology

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 1.3, Item 2.0)

From: David Ehlers

I've been involved in Design Engineering a mere three years and have
been coding FPGA's in VHDL for almost two of those years. I've
recently been given the task of starting up our company's
presently-non-existent verification methodology.

We design avionics displays and find ourselves getting deeper and
deeper into certification issues. Our Software Department is
well-acquainted with these tasks, but we are unsure of how they apply
to FPGA designs. None of our current projects have demanded FPGA
verification but we can see the writing on the wall.

Besides testbenching, what other components contribute to
verification?

Any advice on our start-up efforts is appreciated. Thanks.

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 1.3, Item 2.1)

From: Bernie DeLay

David, you have hit the nail on the head. There is more then just
writing testbenchs when it comes to certification issues for any
avionics application. "Proof of verification" on all system
requirements is of primary concern. But how is that accomplished? It
starts with a thorough Design Specification that provides sufficient
detail to not only design the FPGA, but to also make enumeration of
the requirements possible. You will need to reference a unique
requirement later in the verification process.

The next step, even before coding starts, is to develop a Test Plan
detailing how each requirement will be tested. A matrix
cross-referencing the enumerated Design Spec requirement and the test
plan is a useful means to prove all requirements have been accounted
for. FPGAs do provide the unique opportunity to verify some features
on an actual part. But remember that is not always a viable or
efficient means of verification. Especially if best and worst case
conditions need to be verified. Which is something you need to prove!
Don't fall into the trap of just saying your going to prove it on the
programmed part.

You are now ready to allocate these tests into specific
testbenches. It is convenient to add the testbench to the matrix you
have already developed. You might as well prioritize the testbenches
and add the responsible engineer at this point. They are steps you
should be taking along the way.

Coding can now start! Depending on the criticality level your display
provides, a separate verification engineer may aide your "proof of
verification". Even if it is not required, a 2nd interpretation of the
design specification will increase the likelihood of success. It also
provides an opportunity for parallel verification. That is if a
behavioral model is written ;)

Code coverage tools are an aide in your verification task. Use them
and document their use in the Test Plan. Remember they don't prove
functionality has been checked for proper operation, only that it has
been exercised.

Reviews should be part of your process. Items that need to be reviewed
include the Design Specification, Test Plan and code. A final review
at the end of verification to assure completeness should also be
done. Keep minutes of these reviews.

On last thing. Document this procedure and keep artifacts from each
step. The documented procedure will provide a standard that all
verification engineers can follow. This along with the artifacts will
provide proof to your customer that a thorough verification of all
system requirements was performed.

This should be a good starting point. There are things I haven't taken
up yet like revision control, release control, issue tracking, etc
that should also be part of your process! Don't be afraid to talk to
your Software Department on how they handle many of these same
issues. There is no need to solve the same problem twice.

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 1.4, Item 5.0)

From: Bruce Wolfson

Hi Janick,

I just wanted to say thanks for you starting this verification forum.
I also wanted to thank both Bernie DeLay and David Murray. I
appreciate seeing user input on methodology. Knowing the ins and outs
of a particular tool are great but it does no good if someone is using
a flawed methodology. Keep up the good work.

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 1.5, Item 10.0)

From: Peet James

I gave a paper at Boston Snug that spells out some of the other
ingrediants of highend verification. Paper is called: "Recipe for
multi million gate asics". It is not fpga specific, but you may find
it helpful Goto:

http://www.snug-universal.org/boston/bostonsnug99_papers.html.

You need a synopsys customer login and id, to gain full access