Assignment (variable or signal)?

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

Amal

Amal wrote:

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

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

Paul Uiterlinden

> Amal wrote:
>> 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?

Paul Uiterlinden wrote:
> 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

Mike Treseler

Mike Treseler wrote:

>> Amal wrote:
>>> 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?
>
> Paul Uiterlinden wrote:
>> 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.

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.

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

Paul Uiterlinden

Paul Uiterlinden wrote:

> 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

Mike Treseler

On Nov 21, 4:02 pm, Amal <akhailt...@gmail.com> wrote:
> 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

Andy

Andy wrote:

> 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

Mike Treseler

On Mon, 26 Nov 2007 12:03:08 -0800,
Mike Treseler <> wrote:

>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

http://www.MYCOMPANY.com

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

Jonathan Bromley