VHDL, BFM and shared variables

Hi there,

I am trying to create a VHDL BFM for a propretrary serial protocol. I
have done a bit of reading and have found a few examples with google.
Most of the BFM examples have a command bus (global signals in a
package) that get passed around the procedures that initiate
transactions. For example:
MEM_READ(CMD, ADDR, DATA);
But I would rather call the procedure this way:
MEM_READ(ADDR, DATA);

Unfortunately I cannot figure out how to pass the control information
between the transaction generator and my transaction trigger
procedures. The only way I can see this being done is by using shared
variables, but that has it's own problems.

Can anyone point me in the right direction?

Kind regards,
Ian Barnes.

ian.barnes@renishaw.com

wrote:

> Hi there,
>
> I am trying to create a VHDL BFM for a propretrary serial protocol. I
> have done a bit of reading and have found a few examples with google.
> Most of the BFM examples have a command bus (global signals in a
> package) that get passed around the procedures that initiate
> transactions. For example:
> MEM_READ(CMD, ADDR, DATA);
> But I would rather call the procedure this way:
> MEM_READ(ADDR, DATA);
>
> Unfortunately I cannot figure out how to pass the control information
> between the transaction generator and my transaction trigger
> procedures. The only way I can see this being done is by using shared
> variables, but that has it's own problems.
>
> Can anyone point me in the right direction?

Use a signal plus resolution function for communication between client and
server (transaction trigger procedures called from testbench and the
transaction generator).

Hopefully this will give you an idea:
http://groups.google.com/group/comp....5574c4e8034cd8

--

Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

Paul Uiterlinden

<> wrote in message
news:bfa47b78-f569-466a-a258-...
> Hi there,
>
> I am trying to create a VHDL BFM for a propretrary serial protocol. I
> have done a bit of reading and have found a few examples with google.
> Most of the BFM examples have a command bus (global signals in a
> package) that get passed around the procedures that initiate
> transactions. For example:
> MEM_READ(CMD, ADDR, DATA);
> But I would rather call the procedure this way:
> MEM_READ(ADDR, DATA);
>
> Unfortunately I cannot figure out how to pass the control information
> between the transaction generator and my transaction trigger
> procedures. The only way I can see this being done is by using shared
> variables, but that has it's own problems.
>
> Can anyone point me in the right direction?
>

You can make the 'mem_read' (and other procedures) that do not have 'cmd'
local to the process that calls them. They in turn would call the
'mem_read' that does have 'cmd' which would be defined in the architecture.
Something like this

architecture RTL of MyEntity is
procedure MEM_READ(CMD, ADDR, DATA) is
....
end procedure MEM_READ;

signal Addr, Data, Cmd;
begin

process
procedure MEM_READ(ADDR, DATA) is
mem_read(Cmd, Addr, Data);
end procedure MEM_READ;
begin
....
mem_read(Addr, Data);
end process;

The downside to this is that the simpler form of mem_read (without 'cmd')
needs to be defined within each process that uses them so if your testbench
architecture has several processes, you'll have to copy/paste them so that
they will be available to all. In that situation, I generally mark off the
start and end of the copy/paste area and when I update one of the procedures
for some reason I go through and do the copy/pasting. On the other hand if
your testbench has only process it is not a problem at all.

KJ

KJ

Ian,
I use records whose members have resolved types.

For details see my DesignCon 2003 paper titled,
"Accelerating Verification Through Pre-Use of
System-Level Testbench Components" that is posted at:
http://www.synthworks.com/papers/

If you read Paul's and other postings, you will see
that it is not too much trouble to write resolution
functions for other types (such as integers, real,
and time).

Alternately, you could also take our class,
VHDL Testbenches and Verification, that covers this
and more - like how to do constrained random test
generation and data structures such linked-lists and scoreboards.
See: http://www.synthworks.com/vhdl_testb...rification.htm

Best,
Jim
SynthWorks VHDL Training


> Hi there,
>
> I am trying to create a VHDL BFM for a propretrary serial protocol. I
> have done a bit of reading and have found a few examples with google.
> Most of the BFM examples have a command bus (global signals in a
> package) that get passed around the procedures that initiate
> transactions. For example:
> MEM_READ(CMD, ADDR, DATA);
> But I would rather call the procedure this way:
> MEM_READ(ADDR, DATA);
>
> Unfortunately I cannot figure out how to pass the control information
> between the transaction generator and my transaction trigger
> procedures. The only way I can see this being done is by using shared
> variables, but that has it's own problems.
>
> Can anyone point me in the right direction?
>
> Kind regards,
> Ian Barnes.

Jim Lewis

On 27 Nov, 12:33, Paul Uiterlinden <puit...@notaimvalley.nl> wrote:
> Use a signal plus resolution function for communication between client and
> server (transaction trigger procedures called from testbench and the
> transaction generator).
> Hopefully this will give you an idea:http://groups.google.com/group/comp....5574c4e8034cd8
> --
>
> Paul Uiterlindenwww.aimvalley.nl
> e-mail addres: remove the not.- Hide quoted text -
>
> - Show quoted text -

Thanks for your responses Paul, KJ and Jim. I wasn't expecting that
many so quickly.

I was aware of the ideal of using a global signal and resolution
function to communicate between the client and server - and that this
global signal could be wrapped locally to the process it's used in to
get rid of the reference to the global signal... but... I know that
there is perhaps a better way.

I know there is a better way because on an unrelated project I have
been provided with a compiled library of a BFM for our simulation
environment. This BFM only uses pure procedures to communicate with
the BFM model and does not require the passing in of a global signal
command bus.

I would love to get to the bottom on how they achieve this. Any ideas?

Cheers,
Ian Barnes

ian.barnes@renishaw.com

wrote:

> Thanks for your responses Paul, KJ and Jim. I wasn't expecting that
> many so quickly.
>
> I was aware of the ideal of using a global signal and resolution
> function to communicate between the client and server - and that this
> global signal could be wrapped locally to the process it's used in to
> get rid of the reference to the global signal... but... I know that
> there is perhaps a better way.
>
> I know there is a better way because on an unrelated project I have
> been provided with a compiled library of a BFM for our simulation
> environment. This BFM only uses pure procedures to communicate with
> the BFM model and does not require the passing in of a global signal
> command bus.
>
> I would love to get to the bottom on how they achieve this. Any ideas?

Not right away. I would like to see how it is done.

Not knowing the exact implementation, is see a limitation though. I think
you can have only one instance of your BFM in testbench. It there is more
than one, there is no way to address the correct BFM.

By using a signal as a communication channel, this problem does not exist.
Two instances of the same BFM would use two separate signals via their port
maps. You address the correct BFM by using the correct signal as parameter
in your procedure calls.

Having a single signal as communication channel is not a bad solution, in my
opinion. It is only one parameter in the procedure calls.

The only thing that is a bit daunting in the beginning is the resolution
function and the fact that communication and handshaking happens in delta
time. Because of this, it may be necessary to increase IterationLimit in
modelsim.ini if a lot of commands are called that do not consume time.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

Paul Uiterlinden