Test Harness Strategies

[fabbl]

Anyone using these?

I am a bit confused by the one in Janick Bergeron's "Writing Testnenches -
Functional Verification of HDL Models". In particular how the test record
gets mapped to the DUT signals through the tester for use by the test cases.
Can anyone shed any light on the implementation?

 

[Jim Lewis]

Fabbl,

Anyone using these?
Yep.

I am a bit confused by the one in Janick Bergeron's "Writing Testnenches -
Functional Verification of HDL Models". In particular how the test record
gets mapped to the DUT signals through the tester for use by the test cases.
Can anyone shed any light on the implementation?

We offer classes on this with complete working examples,
see http://www.synthworks.com

To get you started in the right direction,
I did a paper for DesignCon 2003 that has examples of our
record based method for connecting a stimulus generator
to a bus functional model.

See webpage: http://www.synthworks.com/papers/
Look for DesignCon 2003 (on left of page)
Paper title is:
"Accelerating Verification Through Pre-Use of
System-Level Testbench Components"
both the slides and paper are there.

There are some interesting problems to solve with
using records. In general you either have two
records per interface (yuck) or you have to deal with
resolution of multiple drivers (see my paper). To simplify
resolution, use std_logic family types in the record and
tristate signals not driven by a particular design.
Examples of this are in the paper.

The actual connection of the record to the DUT depends
on the testbench model. In the component transaction based
models that I describe in the paper above, the record does
not connect directly to the DUT. The record connects
between the stimulus generator and the BFM. The BFM
connects to the DUT via normal std_logic and std_logic_vector
IO:

Stimulus <== record ==> BFM <== if signals ==> DUT
Generator


It is possible to have an approach like the following:

Stimulus <== record ==> DUT
Generator

It is possible to get some reasonable transaction based
modeling using subprograms in this approach, however, since
subprograms do not have any concurrency, some things are
harder to do (interface sequencing with statemachines).
In addition, with the component based approach, you can include
things like protocol checkers in the BFM.


In the subprogram approach, you connect the record to the
DUT by accessing fields of the record. So the following
is an example:

-- Record definition from a package
type CpuSubRecType is record
Clk : std_logic ;
nAds : std_logic ;
Addr : std_logic_vector (20 downto 0);
Data : std_logic_vector (15 downto 0);
Read : std_logic ;
nRdy : std_logic ;
end record ;

-- Connect Record to DUT in testbench:
architecture Tb of TbChip is
signal CpuRec : CpuSubRecType := InitSubCpuRec ;
begin
U_Chip : entity work.Chip
port map (
Clk => CpuRec.Clk,
nAds => CpuRec.nAds,
Addr => CpuRec.Addr,
Data => CpuRec.Data,
Read => CpuRec.Read,
nRdy => CpuRec.nRdy,
. . .
);
ClkProc : process
. . .

CpuProc : process
. . .


The examples and the paper are excerpts from
SynthWorks' VHDL Testbenches and Verification class.
Details at:
http://www.synthworks.com/vhdl_testbench_verification.htm

Class is offered on-site and in public venues:
http://www.synthworks.com/public_vhdl_courses.htm

Cheers,
Jim Lewis
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~