Assignment (variable or signal)?

[Amal]

Assuming you have a procedure that has a few output values. You need
one such output to be either a signal or a variable. Overloading does
not seem to work in this sense.

procedure p( signal s : out std_logic ) is
begin
s <= '1';
end procedure p;

procedure p( variable v : out std_logic ) is
begin
v := '1';
end procedure p;

I do NOT want to use a function in this case. Is there any way to do
this in VHDL? That is know if a procedure argument is a signal or a
variable?

-- Amal

 

[Paul Uiterlinden]

Assuming you have a procedure that has a few output values. You need
one such output to be either a signal or a variable. Overloading does
not seem to work in this sense.

procedure p( signal s : out std_logic ) is
begin
s <= '1';
end procedure p;

procedure p( variable v : out std_logic ) is
begin
v := '1';
end procedure p;

I do NOT want to use a function in this case. Is there any way to do
this in VHDL? That is know if a procedure argument is a signal or a
variable?

As far as I know: you can't. The solution is to have two differently named
procedures. For example p and p_sig.

 

[Mike Treseler]

As far as I know: you can't. The solution is to have two differently named
procedures. For example p and p_sig.

True.
One alternative is to use the default constant
class to pass a *value* sample of a signal or variable
to a procedure or impure function.

See the procedure "rising" here:
http://home.comcast.net/~mike_treseler/rise_count.vhd

Another is to declare procedures in process scope
with direct access to the variables:

procedure inc_tic_count is
begin
TxBitSampleCount_v := TxBitSampleCount_v+1;
end procedure inc_tic_count;


-- Mike Treseler

 

[Paul Uiterlinden]

True.
One alternative is to use the default constant
class to pass a *value* sample of a signal or variable
to a procedure or impure function.

For input parameters you are right. But for the example that the original
poster gave, this is not really an alternative. He specifically asked about
procedures that have output parameters.

 

[Mike Treseler]

For input parameters you are right. But for the example that the original
poster gave, this is not really an alternative. He specifically asked about
procedures that have output parameters.

Sorry.
I should have answered Amal directly and said,
"What I would do is use a function."

-- Mike Treseler

 

[Andy]

Assuming you have a procedure that has a few output values. You need
one such output to be either a signal or a variable. Overloading does
not seem to work in this sense.

procedure p( signal s : out std_logic ) is
begin
s <= '1';
end procedure p;

procedure p( variable v : out std_logic ) is
begin
v := '1';
end procedure p;

I do NOT want to use a function in this case. Is there any way to do
this in VHDL? That is know if a procedure argument is a signal or a
variable?

-- Amal

That's another thing I don't understand why they did it, but it is
definitely in the LRM. But if you can assign a signal with a variable
expression, why not with a subprogram's variable out-mode port? In
fact when you overload operators with function declarations, there is
no need to define the input parameters as signal to accept a signal.
LRM (2000) Section 2.1.1 clearly states that a subprogram [function or
procedure] formal parameter of class variable must be associated with
an actual of class variable. Hmmm... Sounds like that restriction is
not quite extended to operators...

Maybe Jim Lewis will chime in here???

Andy

 

[Mike Treseler]

That's another thing I don't understand why they did it, but it is
definitely in the LRM. But if you can assign a signal with a variable
expression, why not with a subprogram's variable out-mode port?

I don't know why, but it is plausible
that it covers some edge case.
The default constant class
enforces pass by value, which is safe.

Variable class is a pass by reference and the
variable could be an access type.
Note also that this class is
mysteriously and completely disallowed for functions.
Hmmm.

-- Mike Treseler

 

[Jonathan Bromley]

The default constant class
enforces pass by value, which is safe.

Depressingly, it *doesn't* and it's *not* safe.
The LRM explicitly licenses tools to pass-by-ref
in the interests of efficiency. Given that we have
perfectly good pass-by-ref mechanisms anyway, it's
completely idiotic - and badly broken.

The LRM regards any program that relies on the
difference as "erroneous" (translation: you're
stuffed, and we're not going to warn you about it).
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.