Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Actual must be a static signal name.

1,137 views
Skip to first unread message

Jon Connell

unread,
Dec 5, 1994, 7:10:04 AM12/5/94
to
The LRM 6.1 says that a "static signal name" is a signal with
static, i.e. constant, parameters and 2.1.1.2 says that actuals
associated with formal signals must be static. OK, that's the
rules, live with them. This doesn't mean to say that it's not
crazy! What's *really* wrong with the following:

procedure foo(signal bar : inout std_logic_vector) is
begin
for ii in bar'range loop
someproc(bar(ii));
end loop;
end;

How else could I possibly implement this? The procedure foo
has to take both std_logic and std_logic_vector, but someproc()
only takes std_logic and it would be a real pain to have two
versions of that procedure too.

--

Jon Connell

E-Mail : alb...@scn.de _/ _/_/_/ _/_/ _/_/_/
Fax : +49 (0)89 722 27544 _/ _/ _/ _/ _/
Telephone : +49 (0)89 722 28790 _/ _/ _/ _/ _/
Snail-Mail : Siemens AG, OeN TN ET D33 _/ _/_/_/ _/_/_/ _/_/_/
Postfach 700071
D-81359 Munich SIEMENS IC DESIGN CENTER

Jacques Rouillard

unread,
Dec 6, 1994, 4:02:06 AM12/6/94
to
In article <3buvus$n...@wall.scn.de>, alb...@wall.scn.de (Jon Connell) writes:

|> What's *really* wrong with the following:
|>
|> procedure foo(signal bar : inout std_logic_vector) is
|> begin
|> for ii in bar'range loop
|> someproc(bar(ii));
|> end loop;
|> end;
|>

The actual has to be a static name because everything in VHDL is made to
ensure that all drivers are known at elaboration time. In many cases
the rule is overkill, either because the context makes it easy to
determine the drivers (eg, procedure declared within a
block) or because a reasonnably smart compiler can infer good
properties from the model (like here), but some rule is indeed needed.
I guess that the original language designers tried to make it simple, if
not handy.

The only workaround I can see here is to make names static, i.e. to
explode the call of 'someproc(bar(ii))' into N calls encapsulated in a
case statement, assuming that the range is known at compile-time (if it
is not, then maybe there was a real problem after all).

Yes, that's ugly, but bodies are hidden, aren't they ?

--
---------------------------------------------------------------------------
Jacques Rouillard - t(..33)91054342 f(..33)91700659 email roui...@acm.org
ECSI VHDL Technical Center - ESIM, 13451 Marseille cedex 20, France
---------------------------------------------------------------------------
Experts do not know, either, but at a higher level.
---------------------------------------------------------------------------

Ashutosh Singla

unread,
Dec 5, 1994, 12:56:45 PM12/5/94
to
In article <3buvus$n...@wall.scn.de>, alb...@wall.scn.de (Jon Connell) writes:
Hello,

There is nothing wrong with your code. It is perfectly fine. The only
care which you have to take is that when you are using this procedure, the
parameter should be constrained(obviously).

I hope this is what you had been looking for.

Ashutosh Singla

Bert Molenkamp

unread,
Dec 13, 1994, 6:18:44 AM12/13/94
to
alb...@wall.scn.de (Jon Connell) writes:
> The LRM 6.1 says that a "static signal name" is a signal with
> static, i.e. constant, parameters and 2.1.1.2 says that actuals
> associated with formal signals must be static. OK, that's the
> rules, live with them. This doesn't mean to say that it's not
> crazy! What's *really* wrong with the following:
>
> procedure foo(signal bar : inout std_logic_vector) is
> begin
> for ii in bar'range loop
> someproc(bar(ii));
> end loop;
> end;
>
> How else could I possibly implement this? The procedure foo
> has to take both std_logic and std_logic_vector, but someproc()
> only takes std_logic and it would be a real pain to have two
> versions of that procedure too.
>
If you want that the procedure foo accepts objects of type
a) std_logic_vector, and
b) std_logic
You need indeed TWO procedures. There is a difference between:
signal vector : std_logic_vector(0 to 0);
and signal elem : std_logic;

For the first one the " 'RANGE "attribute is defined. Not for the
last one! So I think you SECOND overloaded procedure will have
the form:
procedure foo (signal bar : inout std_logic) is
begin
someproc(bar);
end foo;


Bert Molenkamp
Dept. of Computer Science
University of Twente
PO Box 217
7500 AE Enschede
the Netherlands
email: mole...@cs.utwente.nl

0 new messages