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:
[email protected]
SynthWorks Design Inc.
http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
