Go Back   Velocity Reviews > Newsgroups > VHDL
User Name
Password
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

Reply

VHDL - Scope interpretation - Bug in ModelTech?

 
Thread Tools Search this Thread
Old 05-25-2004, 11:08 PM   #1
Default Scope interpretation - Bug in ModelTech?


Hello All,

Find below a package that compiles fine with NCSim (version 5.10) but
gives an error with ModelTech 5.7. The error is in this statement:

v_I := pkg_test_use.c_MyConst2;

> ...: cannot find expanded name: pkg_test_use.c_myconst2
> ...: Unkown field: c_myconst2


Apparently, ModelTech only looks at constants that have been declared
in the public part of the package, not in the body.

Now here's the strange part. When I remove the declaration of
c_MyConst, ModelTech doesn't complain anymore. Even though the
statement above doesn't even touch c_MyConst!

Am I overlooking some special scoping rule or is this an (admittedly
obscure) scoping bug?

Tom Verbeure

Here is the complete program:

---------------------------------------------------------
package pkg_test_use is
constant c_MyConst : integer := 1;
end pkg_test_use;

package body pkg_test_use is
constant c_MyConst2 : integer := 100;

function f_Function(Num : in integer) return integer
is
constant c_MyConst2 : integer := 200;
variable v_I : integer;
begin
v_I := c_MyConst2;
v_I := pkg_test_use.c_MyConst2;
return v_I;
end f_Function;
end pkg_test_use;


Wallclimber
  Reply With Quote
Old 05-26-2004, 08:17 AM   #2
Egbert Molenkamp
 
Posts: n/a
Default Re: Scope interpretation - Bug in ModelTech?
IMHO it seems a bug ModelSim and NCsim.
Since c_MyConst2 is not declared in the package (only in the package body) a
VHDL Analayser should complain.
v_I := pkg_test_use.c_MyConst2;
ModelSim does (also the synthesis tool I used; Leonardo). I guess NCSim is
wrong here.

Indeed modelsim does not complain if there is nothing (accept comment) in
the package. That is strange.
(Leonardo still complains "Error, c_MyConst2 is not declared in
pkg_test_use.").
The bug of ModelSim will not effect a real design since an empty package is
not very useful

Send a bug report to both tool vendors (and we are curious how they
respond).

Egbert Molenkamp


"Wallclimber" <> wrote in message
news: om...
> Hello All,
>
> Find below a package that compiles fine with NCSim (version 5.10) but
> gives an error with ModelTech 5.7. The error is in this statement:
>
> v_I := pkg_test_use.c_MyConst2;
>
> > ...: cannot find expanded name: pkg_test_use.c_myconst2
> > ...: Unkown field: c_myconst2

>
> Apparently, ModelTech only looks at constants that have been declared
> in the public part of the package, not in the body.
>
> Now here's the strange part. When I remove the declaration of
> c_MyConst, ModelTech doesn't complain anymore. Even though the
> statement above doesn't even touch c_MyConst!
>
> Am I overlooking some special scoping rule or is this an (admittedly
> obscure) scoping bug?
>
> Tom Verbeure
>
> Here is the complete program:
>
> ---------------------------------------------------------
> package pkg_test_use is
> constant c_MyConst : integer := 1;
> end pkg_test_use;
>
> package body pkg_test_use is
> constant c_MyConst2 : integer := 100;
>
> function f_Function(Num : in integer) return integer
> is
> constant c_MyConst2 : integer := 200;
> variable v_I : integer;
> begin
> v_I := c_MyConst2;
> v_I := pkg_test_use.c_MyConst2;
> return v_I;
> end f_Function;
> end pkg_test_use;





Egbert Molenkamp
  Reply With Quote
Old 05-26-2004, 04:31 PM   #3
Wallclimber
 
Posts: n/a
Default Re: Scope interpretation - Bug in ModelTech?
"Egbert Molenkamp" <> wrote in message news:<c91gb6$7bj$>...
> IMHO it seems a bug ModelSim and NCsim.
> Since c_MyConst2 is not declared in the package (only in the package body) a
> VHDL Analayser should complain.
> v_I := pkg_test_use.c_MyConst2;
> ModelSim does (also the synthesis tool I used; Leonardo). I guess NCSim is
> wrong here.


As, interesting. I tried a whole bunch of scoping tests and it turns
out that NCSim is extremely liberal about scoping rules compared to
MTI. Unfortunately, the LRM is not an easy read about this. Anyway,
it's not that important since in real life, these contructs almost
never happen.

> Send a bug report to both tool vendors (and we are curious how they
> respond).


I did. I'll let know their reaction. If I were them, I'd just ignore
it. I'm sure they have more urgent things to do.

Tom


Wallclimber
  Reply With Quote
Old 05-26-2004, 11:48 PM   #4
Wallclimber
 
Posts: n/a
Default Re: Scope interpretation - Bug in ModelTech?
Find below the answer from Modeltech:

Hi Tom,

This turned out to be tricky issue. We behave right and wrong here.
Right - when we give an error for
v_I := pkg_test_use.c_MyConst2;

Comment from our VHDL guru here.

I believe we are correct here. Section 6.3 on selected names. States
for a prefix that is a package, the suffix denotes an object declared
in the package. If the prefix is not a package, but an entity,
an architecture, a subprogram, a block, a process, or a loop, then
the suffix denotes a object declared immediately within that construct.
Package body is not mention here so only the object declared within
a package are visible.

Wrong - when we don't give an error if the declaration list of package declaration
is empty - that is what was happening when you commented out c_MyConst.

We will fix this incorrect behavior.


Wallclimber
  Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Variable scope toller Hardware 1 04-21-2008 08:28 PM
Out of Scope 70-620 Mike Lynn MCTS 3 03-29-2008 03:36 AM
Variable Scope in asp.Net jansi_rk Software 1 09-18-2006 06:05 PM
Kill Bill v.2 Ending Interpretation: Jordan Lund DVD Video 14 08-18-2004 03:13 AM




SEO by vBSEO 3.3.2 ©2009, Crawlability, Inc.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46