VHDL testbench include?
Tom Loftus
Is there a VHDL equivalent to the Verilog `include directive?
The reason I ask is that when I have written Verilog testbenches
in the past, I have put the code which is common to all my
regression tests into a single file and used `include to include
different test specific code files within it. The appropriate
test could then be run from a script which pointed the include
directive to the appropriate test code.
The common file contained things like the declaration of signals,
instantiation of the device, clock and reset pulses
to start the simulation, input initialization at time zero,
instantiation of models around the device under test, etc.
Then for each test, the included file could do the things
that were unique to that particular test scenario.
How can I achieve the same type of setup with VHDL?
Thanks,
Tom
Colin Marquardt
> Is there a VHDL equivalent to the Verilog `include directive?
That would be a package.
Colin
VhdlCohen
>
If you use transaction based verification, your transactions would be dfined in
a component (or module) called a client, and the interface to the device under
test (DUT) defined in a component called the server. I descibe this approach
in my books, including my latest book.
The client can define the sequence of transactions from within vhdl (thru
processes, and procedures), or from text command files with the use of a parser
and acted upon by the client (see Component Design by Example book).
To achieve different scenareos, use vhdl configurations to select different
command files (if text command files are used within the client), or to define
different client architectures to be used within the testbench.
--------------------------------------------------------------------------
----------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/ vhdl...@aol.com
Author of following textbooks:
* Component Design by Example ... a Step-by-Step Process Using
VHDL with UART as Vehicle", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
--------------------------------------------------------------------------
------------------------------------------
Tom Loftus
>
> >Is there a VHDL equivalent to the Verilog `include directive?
> >
> "That would be a package."
> No, a package would NOT cut it.
I agree, a package is not sufficient to do what I want.
> If you use transaction based verification, your transactions would be dfined in
> a component (or module) called a client, and the interface to the device under
> test (DUT) defined in a component called the server. I descibe this approach
> in my books, including my latest book.
Yes, I was thinking of doing a transaction based approach
but I don't appreciate why you would want to split
the client and server and how you would define the
interface between the two.
I was thinking of having a text file which contained a
sequence of transactions, the parsing of which would control
the test flow. However, it didn't seem desirable to me
to mingle a bunch of unrelated transactions for different
interfaces in the same file that would seem to make the client
transaction parsing very complex.
How do you typically handle it when you have multiple
complex interfaces to the DUT?
Do you typically have one (complex) client to parse a
transaction file and multiple servers to each handle
an interface?
I am concerned that the work involved in the transaction based
verification would exceed that involved in just using multiple
test-specific testbenches.
Tom
VhdlCohen
>dfined in
>> a component (or module) called a client, and the interface to the device
>under
>> test (DUT) defined in a component called the server. I descibe this
>approach
>> in my books, including my latest book.
>
>Yes, I was thinking of doing a transaction based approach
>but I don't appreciate why you would want to split
>the client and server and how you would define the
>interface between the two.
does), then you caN modify the server while reusing the client. On the other
hand, the client could be used for different servers or to identify different
transactions.
>
>I was thinking of having a text file which contained a
>sequence of transactions, the parsing of which would control
>the test flow. However, it didn't seem desirable to me
>to mingle a bunch of unrelated transactions for different
>interfaces in the same file that would seem to make the client
>transaction parsing very complex.
In my book "Component Design by Example", I use a parser package that ncludes
multiple types of transactions, Below is the istruction set for the command
file (extracted from the parser package):
type Instr_enum is
(WRITE1, -- Write a single word @ address with data
RNDM_DATA, -- Write a single word @ address with random data
READ1, -- READ a single word @address
IDLE, -- Stay in IDLE (no load mode) "IDLE 5 -- 5 cycles"
RESET, -- hardware reset for "n" cycles
DISP, -- Displays a message
MODE, -- Uart TB mode
RDUNTIL, -- wait for n clocks and Read until a 1 bit condition is true,
ENVSETUP, -- Sets the hold signal to true/false
CALL, -- Jump to Subroutine: CALL /home/username/taskfile.txt
SYNC, -- Sets sync level
WT4INTRPT, -- wait for interrupt, vector in b inary, 2 bits
STOP -- end of sim
);
Note that some instructions can imply a complex set of cycles by the server.
For example, the RDUNTIL causes the server to read a signal until a condition
is true. At that point the transaction is done. Other instructions allow for
recursive call to subroutines, where the subroutines are defined in files as
command files. The return is the end of the file.
The selection of transactions is up to the user (i.e., not all commands need to
be used).
>
>How do you typically handle it when you have multiple
>complex interfaces to the DUT?
Each interface has its own client, and possibly a different server. The
multiple clients can be synchronized (with the SYNC command) so that one client
would wait until a GO (sync) from the the other clients. I used a resolved
integer signal for the SYNC where the lowest assigned value gets assigned as
the resolved final final. Thus, if unit A assigns a value of 5 onto the sync
signal, and unit B assigns 6, then the sync bus gets resolved to 6. Unit B
gets blocked until unit A assigns a value higher than 5 (integer'high when
done).
>
>Do you typically have one (complex) client to parse a
>transaction file and multiple servers to each handle
>an interface?
That depends upon the problem. For the UART example, I have 2 clients, all
using the same parser package. See my SNUG presentation at my site.
>
>I am concerned that the work involved in the transaction based
>verification would exceed that involved in just using multiple
>test-specific testbenches.
Think of reuse, and ease of debugging with the transaction based verification
method. The transactions can be seen on the waveform viewer so that you can
tranck the response to each trasnsaction. As far as effort, any verification
approach takes a while. My parser package is reusable with minimum effort
because the client generates high level transactions, and leaves the interface
problem to the server. The server interprets each of the transactions, and
executes it. This separations keeps the issues of transactions (or tests)
separate from the implementation (stimulation in server).
>
--------------------------------------------------------------------------
-----------------------------------------