Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Transaction based testbench - Effective encapsulation of the client 'transactors'?

Reply
Thread Tools

Transaction based testbench - Effective encapsulation of the client 'transactors'?

 
 
Andrew FPGA
Guest
Posts: n/a
 
      09-27-2005
Hi Newsgroup,
I am implementing a transaction based testbench and I'm trying to find
an effective way of encapsulating the client calls into my test
harness.

I have a "Test Harness" that is a single VHDL file and contains Bus
Functional Models(BFMs) for all the DUT interfaces. This test harness
also instantiates the DUT and generates the clk/reset for the DUT.
These BFM's can be thought of as servers - they provide a high level
transaction based interface.

Following Janick Bergeron's advice(Writing Testbenches - Functional
Verification of HDL Models, Kluwer Academic Publishers) I have created
a Test Harness Package in a separate file. This contains the BFM
transaction interface definition. Each BFM has a signal record(global)
for sending transactions to the BFM and another signal record(global)
for receiving transactions back from the BFM.

I then have a "Test Case" module(its another file) that acts as a
client to the Server BFM's. The client-server protocol is based around
transactions(no ****). The server BFM implements the server end of the
protocol obviously. Now, where does the client end of the protocol get
implemented? Bergeron suggests encapsulating the client end of the
protocol using procedures located in the test harness package(pg 243).
The problem is that the client server protocol is transaction based -
the server waits on a transaction( wait on ToServer'transaction) and
the client waits on an acknowledge/complete transaction from the
server. To quote the LRM "Attributes of an actual are never passed into
a subprogram". So I can't use the wait on FromServer'transaction
contruct inside my client procedure. Is there an elegent solution to
this? Why is Bergeron suggesting something that is not possible (or is
my understanding wrong somewhere)?

One solution is to use events rather than transactions. i.e. toggle a
signal rather than simply assign to it. But I find the wait on
blah'transaction much more elegant.

Regards
Andrew

 
Reply With Quote
 
 
 
 
ALuPin@web.de
Guest
Posts: n/a
 
      09-27-2005
Hi Andrew,

Try Janick's discussion forum

http://verificationguild.com/index.php

Rgds
André

 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      09-27-2005
Andrew FPGA wrote:

> The problem is that the client server protocol is transaction based -
> the server waits on a transaction( wait on ToServer'transaction) and
> the client waits on an acknowledge/complete transaction from the
> server. To quote the LRM "Attributes of an actual are never passed into
> a subprogram". So I can't use the wait on FromServer'transaction
> contruct inside my client procedure.


You don't have to pass the signal if it
is packaged or otherwise in scope.

http://groups.google.com/groups?q=vh...signal+package

> Why is Bergeron suggesting something that is not possible (or is
> my understanding wrong somewhere)?


Isn't there a full working example in the book?

-- Mike Treseler
 
Reply With Quote
 
Andrew FPGA
Guest
Posts: n/a
 
      09-27-2005
Andre: Thanks, I'll post there too.

Mike Treseler wrote:
> Andrew FPGA wrote:
>
> > The problem is that the client server protocol is transaction based -
> > the server waits on a transaction( wait on ToServer'transaction) and
> > the client waits on an acknowledge/complete transaction from the
> > server. To quote the LRM "Attributes of an actual are never passed into
> > a subprogram". So I can't use the wait on FromServer'transaction
> > contruct inside my client procedure.

>
> You don't have to pass the signal if it
> is packaged or otherwise in scope.

Ok, I can see how that works for a single server. What if you have
multiple servers of the same type though.(e.g. the DUT has multiple
interfaces of the same type). Then I want to be able to pass into the
client procedure the signals for the particular server I want to
communicate with. Having a seperate set of client procedures for every
server instance of the same type gets messy pretty quick.

> http://groups.google.com/groups?q=vh...signal+package
>
> > Why is Bergeron suggesting something that is not possible (or is
> > my understanding wrong somewhere)?

>
> Isn't there a full working example in the book?

Lots of code snippets but no full example for this client/server stuff.
Bergeron shows the client procedure declarations in the package file
but does not go as far as showing the procedure definitions in the
package body. In his client procedure declarations he even has the "to
server" and "from server" transaction signals in the formal paramater
list.

Thank you for your comments Mike.

Regards
Andrew


> -- Mike Treseler


 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      09-27-2005
Andrew FPGA wrote:

> Having a seperate set of client procedures for every
> server instance of the same type gets messy pretty quick.


I agree. Consider a single main test process
and keep things clean and procedural.
See: http://home.comcast.net/~mike_treseler/

>> Isn't there a full working example in the book?


> Lots of code snippets but no full example for this client/server stuff.


I won't critique a book I haven't read,
but I would hesitate to take on such
a complicated test architecture
without seeing one working example.

> Thank you for your comments Mike.


You are welcome.

-- Mike Treseler

 
Reply With Quote
 
Andy Peters
Guest
Posts: n/a
 
      09-28-2005
Andrew FPGA wrote:
> Andre: Thanks, I'll post there too.
>
> Mike Treseler wrote:
> > Andrew FPGA wrote:
> >
> > > The problem is that the client server protocol is transaction based -
> > > the server waits on a transaction( wait on ToServer'transaction) and
> > > the client waits on an acknowledge/complete transaction from the
> > > server. To quote the LRM "Attributes of an actual are never passed into
> > > a subprogram". So I can't use the wait on FromServer'transaction
> > > contruct inside my client procedure.

> >
> > You don't have to pass the signal if it
> > is packaged or otherwise in scope.

> Ok, I can see how that works for a single server. What if you have
> multiple servers of the same type though.(e.g. the DUT has multiple
> interfaces of the same type). Then I want to be able to pass into the
> client procedure the signals for the particular server I want to
> communicate with. Having a seperate set of client procedures for every
> server instance of the same type gets messy pretty quick.
>
> > http://groups.google.com/groups?q=vh...signal+package
> >
> > > Why is Bergeron suggesting something that is not possible (or is
> > > my understanding wrong somewhere)?

> >
> > Isn't there a full working example in the book?

> Lots of code snippets but no full example for this client/server stuff.
> Bergeron shows the client procedure declarations in the package file
> but does not go as far as showing the procedure definitions in the
> package body. In his client procedure declarations he even has the "to
> server" and "from server" transaction signals in the formal paramater
> list.


The reason for this "client/server" approach to VHDL testbenches is
because of VHDL's rules for passing signals through to procedures. For
example, it'd be most excellent if your test bench could call a
DoPCIBurstWrite() procedure inside your pcimaster entity with no
parameters other than say, burst length, and have it go off and do it.
But you can't do that -- you can't call a procedure in another entity
without passing every single signal as a parameter, and if you have a
bunch of signals, things get pretty ugly pretty quickly.

So the "client/server" approach basically has your test bench process
toggling a signal (like, say, doPCIBurstWrite) that is detected by
server process in the server's entity, and then the server process
calls the procedure(s) that actually toggle the signals that need
togglin'.

It's a right royal Pain In The Ass.

This is one area where Verilog kicks VHDL's ass. Of course, Verilog
can easily kick YOUR ass here, since you can't call a function/task if
that function/task is already being executed. Verilog will happily
overwrite everything in the task and bonk you. The fixes here are to
put a "guard" around the task (as noted in Bergeron's book) or use
Verilog-2001 and mark the task as re-entrant.

-a

 
Reply With Quote
 
Andrew FPGA
Guest
Posts: n/a
 
      09-28-2005
For those interested, the solution I am using is to toggle a signal
when signalling between my client/server. That way I can simply wait on
an event.

Janick Bergeron had this to say:
"You are correct - and your understanding has not gone wrong: there is
an error (in fact several errors!) in the book. See
http://janick.bergeron.com/wtb/errata1.html for a list."

Mike: I really do buy into the single process style for my
synthesizable code. This style was quite a revelation to me when I
discovered it here a month or so ago. The only disadvantage I see is
that often I have FSM's with outputs that don't need to be registered
so perhaps some wasted flops with this method. But I am more than
willing to trade this for the huge improvement in code readability. For
now testbenches are a different story, I'm still coming to grips with
the style proposed in that UART example. Probably just need more time
at it and I will get it.

Andy: Its interesting that reuse is often given as a major advantage
and reason why one should persue the client/server approach. But after
reading your comment I suspect yours is the more fundamental reason
this approach is required.

Regards
Andrew

Andy Peters wrote:
> Andrew FPGA wrote:
> > Andre: Thanks, I'll post there too.
> >
> > Mike Treseler wrot"e:
> > > Andrew FPGA wrote:
> > >
> > > > The problem is that the client server protocol is transaction based -
> > > > the server waits on a transaction( wait on ToServer'transaction) and
> > > > the client waits on an acknowledge/complete transaction from the
> > > > server. To quote the LRM "Attributes of an actual are never passed into
> > > > a subprogram". So I can't use the wait on FromServer'transaction
> > > > contruct inside my client procedure.
> > >
> > > You don't have to pass the signal if it
> > > is packaged or otherwise in scope.

> > Ok, I can see how that works for a single server. What if you have
> > multiple servers of the same type though.(e.g. the DUT has multiple
> > interfaces of the same type). Then I want to be able to pass into the
> > client procedure the signals for the particular server I want to
> > communicate with. Having a seperate set of client procedures for every
> > server instance of the same type gets messy pretty quick.
> >
> > > http://groups.google.com/groups?q=vh...signal+package
> > >
> > > > Why is Bergeron suggesting something that is not possible (or is
> > > > my understanding wrong somewhere)?
> > >
> > > Isn't there a full working example in the book?

> > Lots of code snippets but no full example for this client/server stuff.
> > Bergeron shows the client procedure declarations in the package file
> > but does not go as far as showing the procedure definitions in the
> > package body. In his client procedure declarations he even has the "to
> > server" and "from server" transaction signals in the formal paramater
> > list.

>
> The reason for this "client/server" approach to VHDL testbenches is
> because of VHDL's rules for passing signals through to procedures. For
> example, it'd be most excellent if your test bench could call a
> DoPCIBurstWrite() procedure inside your pcimaster entity with no
> parameters other than say, burst length, and have it go off and do it.
> But you can't do that -- you can't call a procedure in another entity
> without passing every single signal as a parameter, and if you have a
> bunch of signals, things get pretty ugly pretty quickly.
>
> So the "client/server" approach basically has your test bench process
> toggling a signal (like, say, doPCIBurstWrite) that is detected by
> server process in the server's entity, and then the server process
> calls the procedure(s) that actually toggle the signals that need
> togglin'.
>
> It's a right royal Pain In The Ass.
>
> This is one area where Verilog kicks VHDL's ass. Of course, Verilog
> can easily kick YOUR ass here, since you can't call a function/task if
> that function/task is already being executed. Verilog will happily
> overwrite everything in the task and bonk you. The fixes here are to
> put a "guard" around the task (as noted in Bergeron's book) or use
> Verilog-2001 and mark the task as re-entrant.
>
> -a


 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      09-29-2005
Andy Peters wrote:

> The reason for this "client/server" approach to VHDL testbenches is
> because of VHDL's rules for passing signals through to procedures. For
> example, it'd be most excellent if your test bench could call a
> DoPCIBurstWrite() procedure inside your pcimaster entity with no
> parameters other than say, burst length, and have it go off and do it.
> But you can't do that -- you can't call a procedure in another entity
> without passing every single signal as a parameter, and if you have a
> bunch of signals, things get pretty ugly pretty quickly.


However, I can always call procedures declared in the
same process and have full access to all signals in
the testbench architecture. For packaged procedures with signal
parameters, I can overload the procedure id in the
main testbench process and enter the signal signal
identifiers only once in the overload declaration.

> So the "client/server" approach basically has your test bench process
> toggling a signal (like, say, doPCIBurstWrite) that is detected by
> server process in the server's entity, and then the server process
> calls the procedure(s) that actually toggle the signals that need
> togglin'.
> It's a right royal Pain In The Ass.


I agree.

-- Mike Treseler
 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      09-29-2005
Andrew FPGA wrote:

> Mike: I really do buy into the single process style for my
> synthesizable code. This style was quite a revelation to me when I
> discovered it here a month or so ago. The only disadvantage I see is
> that often I have FSM's with outputs that don't need to be registered
> so perhaps some wasted flops with this method.


If I am using an FPGA, the gates come with flops.
I can either bypass them with spaghetti code
or just let them be with the template. Note
that a variable can represent a combinational net
inside the process. The mandatory register only
applies to port outputs. If I bypass registers
on port outputs, static timing of multi-module
designs is more difficult to close and debug.

> For
> now testbenches are a different story, I'm still coming to grips with
> the style proposed in that UART example. Probably just need more time
> at it and I will get it.


Start by running the simulation and looking at the waveforms.
The main point is that the executive process delays are synchronized
by the "tic" procedure. This makes it easy to model complex stimulus
cycles. The trick is to run stimulus right up to the tick
where a known signal value is expected, and check it before
another tic; occurs.

-- Mike Treseler
 
Reply With Quote
 
Klaus Falser
Guest
Posts: n/a
 
      09-29-2005
In article <(E-Mail Removed) .com>,
http://www.velocityreviews.com/forums/(E-Mail Removed) says...
> Hi Newsgroup,
> I am implementing a transaction based testbench and I'm trying to find
> an effective way of encapsulating the client calls into my test
> harness.
>
> I have a "Test Harness" that is a single VHDL file and contains Bus
> Functional Models(BFMs) for all the DUT interfaces. This test harness
> also instantiates the DUT and generates the clk/reset for the DUT.
> These BFM's can be thought of as servers - they provide a high level
> transaction based interface.
>
> Following Janick Bergeron's advice(Writing Testbenches - Functional
> Verification of HDL Models, Kluwer Academic Publishers) I have created
> a Test Harness Package in a separate file. This contains the BFM
> transaction interface definition. Each BFM has a signal record(global)
> for sending transactions to the BFM and another signal record(global)
> for receiving transactions back from the BFM.
>
> I then have a "Test Case" module(its another file) that acts as a
> client to the Server BFM's. The client-server protocol is based around
> transactions(no ****). The server BFM implements the server end of the
> protocol obviously. Now, where does the client end of the protocol get
> implemented? Bergeron suggests encapsulating the client end of the
> protocol using procedures located in the test harness package(pg 243).
> The problem is that the client server protocol is transaction based -
> the server waits on a transaction( wait on ToServer'transaction) and
> the client waits on an acknowledge/complete transaction from the
> server. To quote the LRM "Attributes of an actual are never passed into
> a subprogram". So I can't use the wait on FromServer'transaction
> contruct inside my client procedure. Is there an elegent solution to
> this? Why is Bergeron suggesting something that is not possible (or is
> my understanding wrong somewhere)?
>
> One solution is to use events rather than transactions. i.e. toggle a
> signal rather than simply assign to it. But I find the wait on
> blah'transaction much more elegant.
>
> Regards
> Andrew
>


Just to be curious.
Anybody knows why it's not allowed to use attributes like 'delayed or
'transaction in procedures?
The only reason I can see is that the simulator would be more
complicated since its only known at elaboration for
which signals the implicit signals behind this attributes have to be
constructed.

Regards
Klaus
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
File-based Code Encapsulation Trans Ruby 6 01-05-2007 04:03 AM
Win2003 SP1 error: "New transaction cannot enlist in the specified transaction coordinator" Vencz Istv?n ASP General 2 05-02-2005 05:53 AM
TCP over IPSEC NAT encapsulation anth0 Cisco 0 12-18-2003 01:19 PM
question about encapsulation for ethernet ? brian Cisco 1 11-28-2003 04:23 PM
Is transaction-based debugging useful ? ben cohen VHDL 0 08-20-2003 02:03 AM



Advertisments