VHDL - Re: Transaction based testbench - Effective encapsulation of the

Author

Re: Transaction based testbench - Effective encapsulation of the

Jim Lewis

2005-10-04, 7:03 pm

Andrew,
I use a similar approach to what Janick and Ben Cohen do
with the exception that I pass records through interfaces
as inout. To make this work well, I make all record
elements based on std_logic/std_logic_vector/unsigned/signed.
While this is clumsy for some things (such as time),
it can be made to work. Then I initialize all fields to
tristate to resolve multiple drivers introduced by the
records being inout of multiple models. The VHDL-2006
effort is working on a feature called interfaces which
should make usage of any type possible.

For more details on this approach see the 2nd half of the
paper: "Accelerating Verification Through Pre-Use of
System-Level Testbench Components" that I gave at
DesignCon 2003.

I implement the transaction source in a single model I
call the test control (aka client). For each independent
interface, I create a separate process. In the process for
a given interface I make calls to the transaction procedures.
Some models require more than one transaction source to
support their interface behavior - for example a processor
model would require a process for functional transactions
and a separate process for the interrupt handler.

Handshaking between the test control (client) and the
BFM (server) can be anything you like. I use something
more like hardware handshaking just because of the
familiarity of it. The handshaking required may depend
on how the models need to work. Between some models a
level sensitive handshaking may be appropriate - for example
if the test control can issue a transaction to the BFM when
the BFM is busy, the BFM will miss the event on the signal.
Between some models edge sensitive handshaking may be
required - for example if you have a BFM that is a UART
receiver and the BFM does not buffer data, then only a
simple event from the BFM to the test control is required.
If the test control does not accept it, then the received
value is discarded. I also use a modified toggle handshaking
for the back door transaction access I added to my memory
models.

There are many ways to make handshaking work. I have found
a couple that work under different situations and have
encapsulated them into a procedure and don't bother to
think about them too much.

Cheers,
Jim
P.S.
If you use global signals for the transaction records,
then you might find creating arrays of them will help.
Then you assign each separate model an integer index into
the array by using a generic into the BFM.

I suspect that Ben Cohen has some examples of this in
his books.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~

Mike Treseler

2005-10-04, 9:58 pm

Andrew FPGA wrote:
> ...Perhaps it is time for me to purchase
> a more up to date book on verification(VHDL).

You might have to write it first :)

-- Mike Treseler

Jim Lewis

2005-10-05, 7:02 pm

Andrew,
>
>
> Thanks, actually I had already read this paper during my journey to the
> "transaction based testbench" mecca. I found it well written and I
> liked the clear diagrams. It did leave me with a few questions though:
> 1) Figure 12 shows each of the tests being a different implementation
> of the TestCtl architecture. Sounds nice but practically how does one
> string all these different tests together so that I can run all the
> tests(sequentially) through the simulator in one hit. Do I need to
> write scripts to compile Test1, load into sim, run sim, compile Test2,
> load into sim, run sim?

Yes. I have a script run each architecture independently.
Generally I compile them all and then use a configuration
to specify which is run. I put the configuration in the
bottom of TestCtrl even though it technically doesn't belong
there because it configures the top level TB, however, it
works well. I tend to run several simulations rather than
one mondo-long simulation.

> 2) Within TestCtl "each independent source of stimulous is supported by
> one or more processes". The problem I see with this is that the
> stimulous sources are never really independent. From the point of view
> of someone writing the testcase they often want to specify the
> relationship between stimulus starting on various interfaces.

I like to keep interfaces independent and synchronize when
needed to achieve the relationships I need. I have a
procedure just to handle synchronization between processes.

If you run all transaction procedures from one process, your
transactions must be non-blocking and operations like read will
take two interactions with the BFM - one read request and a
follow up to get the value. This complicates the test process.
It also means that when writing the test
you must have knowledge of the number of cycles an operation
takes. If a change is made, you may need to reorder your
transctions. Keep in mind that a design team may not tell a
test team about a change that does not change the big picture
functionality - like increasing the number of states a memory
access takes.

So I have found having separate processes per interface
simplifies how I think of the interactions with the models
and keeps me out of trivial design change issues.
Also with separate processes a BFM only needs a queue when
it needs to be able to execute the transactions you specify
for a test out of order.

>
>
> Hmm, not quite sure why a separate process for each independent
> interface?
For the interrupt handler if for all tests you know apriori
when each interrupt will happen, then you probably don't
need a separate process. This is probably true for all
simple tests. However for the system level testing, often
interrupts from the timers are handled and discarded and do
not impact the flow of the functional transactions. Even
this you could work around, by turning off timer interrupts.

However, again I use the separate processes as it is easier
for me to visualize them running independently and hence it
is easier for me to generate the code.

>
>
> I think this is a very good point. (level sensitive vs edge sensitive
> client/server protocol).

Going further for each class of protocols we need a
standard package that has subprograms that encapsulates
the implementation.

>
>
> I do use global signals for the transaction records. But I'm not quite
> sure I see how your suggestion helps...Each server BFM already has
> visibility of the global transaction records. The global transaction
> records are stored in a package...Perhaps it is time for me to purchase
> a more up to date book on verification(VHDL).

Oops I did not put in all of the details of my stream of
conscious thought ... When I read the thread, it seemed
that someone was concerned
that they need to write a transaction support procedure for
each model - having done this for a while I thought yes this
is quite normal - unless you are writing separate procedures to
handle the case where you need to use a given model more
than once. For example, a print server may support between
1 to 4 printers. Hence, the simulation must be able to
support multiple printer BFMs instantiated. Under this
situation, an easy solution (when using global signals)
is to make the transaction record for the BFM that is used
more than once an array.

If you only have one instance of each type of BFM, then
this is not needed.

Cheers,
Jim

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~

Sponsored Links