Driving signals from a procedure

[Andy Peters]

I'm baffled by how VHDL deals with procedures and driving signals, and
how some things are visible and others aren't. For example, in the
following skeleton a call to the parameterless procedure InitS() calls
the more-generic procedure Init() in order to initialize my signals s1
and s2. The idea is that the procedure InitS() is visible to other
modules in my test bench (its declaration is in a package) and I'm
trying to avoid passing a lot of signals around.

entity foo;
end entity foo;

architecture bar of foo is
signal s1 : std_logic;
signal s2 : std_logic;

-- initialize any two bits.
procedure Init (
signal b1 : out std_logic;
signal b2 : out std_logic ) is
begin
b1 <= '0';
b2 <= '0';
end procedure Init;

-- call InitS to initialize s1 and s2:
procedure InitS is
begin
Init(s1, s2);
end procedure InitS;

begin -- architecture bar of foo
... do whatever
end architecture bar;

When I compile this, I get

"Cannot drive signal 's1' from this subprogram." and
"Cannot drive signal 's2' from this subprogram." errors.

I realize problem here is that signals s1 and s2 are not available to
be assigned from a procedure if they're not passed in as out signal
parameters.

So, what's a reasonable workaround?

-a
[real e-mail: devel (at) latke (dot) net]

 

[Andy Peters]

Mike Treseler wrote:

Andy Peters wrote:

So, what's a reasonable workaround?

I put all the testbench procedures between the
IS and BEGIN of the main test process.
This allows you to access any signal in the
testbench architecture without passing parameters.

Ah, but the "gotcha" in this case is that I want to create a standalone
module -- in this case, it's essentially a signal generator -- that I
can include in my testbench. The idea is that my test bench process
can simply call a "GeneratePattern" procedure in the signal generator
module and have it do its magic.

I found a sorta-solution in Janick Bergeron's book; it's his notion of
"client/server control." I created a global signal (of a custom
"command type") that's twiddled in the main test bench process (the
client), and a process in the signal generator module (the server)
waits on a transaction on that signal. The server parses that command
signal and calls the appropriate procedure.

I hate to say it, but this is one area where Verilog shines; calling
tasks in other modules is as simple as a C function call.

Ah, well!

-a

 

You can call your "generator" procedure within the main process
and pass the signals - if necessary - to a different procedure (again
from
the main process).

Rgds
André