undeclared identifier error message but all libraries are declaredand added (precision)
 

Hey all,

i'm getting the following message when using precision compilation of
the the input files

# Error: File "C:/Program Files/Mentor
Graphics/x_Impl/sources/package_x.vhd", Line 146: Use of 'unsigned'

and this is the part of the code that is generating the error:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use IEEE.NUMERIC_STD.ALL;

package package_x is

constant x_unsigned : unsigned(3 downto 0):="1111";

end package_x;


package body package_x is


end package_x;

what am i doing wrong? the packages are added, the libraries declared?

Can someone help me, thank you ...

kind regards,

Yttrium

Re: undeclared identifier error message but all libraries are declared and added (precision)
 

On Mon, 01 Jan 2007 18:48:00 +0100, yttrium
<yttrium@telenet.be> wrote:

[...]

>and this is the part of the code that is generating the error:

>library IEEE;
>use IEEE.STD_LOGIC_1164.ALL;
>use IEEE.STD_LOGIC_ARITH.ALL;
>use IEEE.STD_LOGIC_UNSIGNED.ALL;
>use IEEE.NUMERIC_STD.ALL;
>
>package package_x is
> constant x_unsigned : unsigned(3 downto 0):="1111";
>end package_x;

>what am i doing wrong? the packages are added, the libraries declared?

Standard Answer #1347: Please stop messing around with the ugly,
incomplete, poorly-standardised packages STD_LOGIC_ARITH and
STD_LOGIC_UNSIGNED. The standard package NUMERIC_STD
does all you need.

Standard Answer #2754: You have imported two different packages
(STD_LOGIC_ARITH and NUMERIC_STD) both of which define the
type UNSIGNED. Consequently, the definition of UNSIGNED is hidden.

There are two ways to fix your problem:

a) the stupid but interesting way: Use a qualified name for UNSIGNED.
constant x_unsigned: NUMERIC_STD.unsigned(3 downto 0) := "1111";

b) the sensible and delightfully dull way: Get rid of the unnecessary
use clauses...
--use IEEE.STD_LOGIC_ARITH.ALL;
--use IEEE.STD_LOGIC_UNSIGNED.ALL;
and use only NUMERIC_STD.
--
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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

Re: undeclared identifier error message but all libraries are declaredand added (precision)
 

Jonathan Bromley wrote:
> On Mon, 01 Jan 2007 18:48:00 +0100, yttrium
> <yttrium@telenet.be> wrote:
>
> [...]
>
>> and this is the part of the code that is generating the error:
>
>> library IEEE;
>> use IEEE.STD_LOGIC_1164.ALL;
>> use IEEE.STD_LOGIC_ARITH.ALL;
>> use IEEE.STD_LOGIC_UNSIGNED.ALL;
>> use IEEE.NUMERIC_STD.ALL;
>>
>> package package_x is
>> constant x_unsigned : unsigned(3 downto 0):="1111";
>> end package_x;
>
>> what am i doing wrong? the packages are added, the libraries declared?
>
> Standard Answer #1347: Please stop messing around with the ugly,
> incomplete, poorly-standardised packages STD_LOGIC_ARITH and
> STD_LOGIC_UNSIGNED. The standard package NUMERIC_STD
> does all you need.
>
> Standard Answer #2754: You have imported two different packages
> (STD_LOGIC_ARITH and NUMERIC_STD) both of which define the
> type UNSIGNED. Consequently, the definition of UNSIGNED is hidden.
>
> There are two ways to fix your problem:
>
> a) the stupid but interesting way: Use a qualified name for UNSIGNED.
> constant x_unsigned: NUMERIC_STD.unsigned(3 downto 0) := "1111";
>
> b) the sensible and delightfully dull way: Get rid of the unnecessary
> use clauses...
> --use IEEE.STD_LOGIC_ARITH.ALL;
> --use IEEE.STD_LOGIC_UNSIGNED.ALL;
> and use only NUMERIC_STD.

you are right ... thank you for your help ...

can you explain very quickly what the difference is between the numeric
and arith/unsigned library? (numeric library more up-to-date?)

thanks

Re: undeclared identifier error message but all libraries are declaredand added (precision)
 

yttrium wrote:
> can you explain very quickly what the difference is between the numeric
> and arith/unsigned library? (numeric library more up-to-date?)
>

numeric_std = maintained, IEEE standard
std_logic_arith = vendor implemented shareware, but not maintained

There will be additional benefits to numeric_std in the next
revision of the language with respect to locally static.
If you have questions, please read the papers on VHDL-2006 at:
http://www.synthworks.com/papers

Cheers,
Jim Lewis
VHDL Evangelist

Re: undeclared identifier error message but all libraries are declared and added (precision)
 

On Mon, 01 Jan 2007 23:49:51 +0100, yttrium
<yttrium@telenet.be> wrote:

>can you explain very quickly what the difference is between the numeric
>and arith/unsigned library? (numeric library more up-to-date?)

I don't disagree with Jim, but from a purely practical point
of view here are the big things (personal preconceptions
only, form your own viewpoint as soon as you can!):

std_logic_(un)signed: an invention of the devil, put there
merely to satisfy drongos who can't be bothered to think
about data types when writing counters and suchlike,
and who want to be able to do Count<=Count+1 on
a std_logic_vector. Don't use them.

std_logic_arith: contains much of the useful stuff in
numeric_std, but is not as complete. Many simple
designs can use either std_logic_arith or numeric_std
without change. However, the type-conversion functions
in numeric_std have much more sensible names
(T0_INTEGER from numeric_std is self-explanatory,
but CONV_INTEGER from std_logic_arith? Is is
converting FROM or TO integer???). And, as Jim
said, numeric_std is truly standardised and is
properly maintained.
--
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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

Re: undeclared identifier error message but all libraries are declaredand added (precision)
 

Jim Lewis wrote:
> yttrium wrote:
>> can you explain very quickly what the difference is between the
>> numeric and arith/unsigned library? (numeric library more up-to-date?)
>>
>
> numeric_std = maintained, IEEE standard
> std_logic_arith = vendor implemented shareware, but not maintained
>
> There will be additional benefits to numeric_std in the next
> revision of the language with respect to locally static.
> If you have questions, please read the papers on VHDL-2006 at:
> http://www.synthworks.com/papers
>
> Cheers,
> Jim Lewis
> VHDL Evangelist

thanks for the very interesting link ....

Re: undeclared identifier error message but all libraries are declaredand added (precision)
 

Jonathan Bromley wrote:
> On Mon, 01 Jan 2007 23:49:51 +0100, yttrium
> <yttrium@telenet.be> wrote:
>
>> can you explain very quickly what the difference is between the numeric
>> and arith/unsigned library? (numeric library more up-to-date?)
>
> I don't disagree with Jim, but from a purely practical point
> of view here are the big things (personal preconceptions
> only, form your own viewpoint as soon as you can!):
>
> std_logic_(un)signed: an invention of the devil, put there
> merely to satisfy drongos who can't be bothered to think
> about data types when writing counters and suchlike,
> and who want to be able to do Count<=Count+1 on
> a std_logic_vector. Don't use them.
>
> std_logic_arith: contains much of the useful stuff in
> numeric_std, but is not as complete. Many simple
> designs can use either std_logic_arith or numeric_std
> without change. However, the type-conversion functions
> in numeric_std have much more sensible names
> (T0_INTEGER from numeric_std is self-explanatory,
> but CONV_INTEGER from std_logic_arith? Is is
> converting FROM or TO integer???). And, as Jim
> said, numeric_std is truly standardised and is
> properly maintained.

thank you for the help and information, i will definitely take a closer
look at the different packages now ...

kind regards,

y

Re: undeclared identifier error message but all libraries are declaredand added (precision)
 

Jonathan,
> std_logic_(un)signed: an invention of the devil, put there
> merely to satisfy drongos who can't be bothered to think
> about data types when writing counters and suchlike,
> and who want to be able to do Count<=Count+1 on
> a std_logic_vector. Don't use them.

"Drogo" must be one of those British English terms
that doesn't translate to American English. :)

WRT, std_logic_signed I agree - in fact, I rarely admit
it even exists, but since you mentioned it I thought I
would comment.

In the big picture of methodology, I think whether you use
std_logic_unsigned or not you face a devil in some problems.

Sure, for RTL counters as you suggest above, using unsigned
is a great way to avoid any any devils in that problem, however,
I am not sure how once you expand your view, that you avoid
some devil (be it methodology cop, coding clarity, or
coding correctness).

Let me elaborate:

For testbenches, where one needs to add to the address as part
of the algorithm, what do you do? Note that address is only a
collection of bits and, hence, is std_logic_vector.
I see the options as (feel free to add some if I missed something),
but I am curious as to which you think are less of a devil and why.
1) Use type conversions:
address <= std_logic_vector(unsigned(address) + 1)) ;

The big point here is "+1" (or other algorithm) not the
type conversions, although the type conversions dominate
what most people readily see.
This violates the testbench rule of layering and abstracting
your testbench operations/transactions to increase readability
and usability.


2) Use type unsigned (eventhough it is really std_logic_vector)
and convert at the port:
address_unsigned <= address_unsigned + 1 ;

and then at the port map (only address portion):
address => std_logic_vector(address_unsigned),

And if it were a bidirectional object:
unsigned(data) => std_logic_vector(data_unsigned),

Methodology wise, is it ok to use a different data type in the
testbench just because you want to do math?
Do you do all std_logic_vector signals as unsigned (assuming that
you use unsigned and signed for math objects)? Methodology wise
this feels wrong.

Do you only use unsigned when you need to and, hence, change them
reactively or on detailed analysis of the entire testplan (which
at any point in time could be incomplete). This would be tedious
and subject you to lots of compile errors for things you did not
convert - it also may lead you to needing to encode the type of
the data into the object name.


3) Use std_logic_unsigned:
address <= address + 1 ;

Your friend ;)


OTOH, in RTL code if you don't use std_logic_unsigned and
you are accustomed to writing:
if unsigned(Address) > "01001" then

What happens if you forget the type conversion:
if Address > "01001" then

Yikes - both of these compile, however, if Address is not
5 bits this is a potential bug.


My point being that this is not as crystal clear problem as
many wish it to be. I find myself least troubled by using
a package that provides unsigned math operations for
std_logic_vector.

Cheers,
Jim
VHDL Evangelist

Re: undeclared identifier error message but all libraries are declared and added (precision)
 

On Tue, 02 Jan 2007 08:26:20 -0800, Jim Lewis
<jim@synthworks.com> wrote:

Jim, thanks for the interesting thought-provokers.

>"Drongo" must be one of those British English terms
>that doesn't translate to American English. :)

Aw, let me have my little New Year rant :-) I suspect
"lamebrain" comes close, but it's a bit too literal for
Brit tastes so we go for "drongo" or "numpty". Anyways,
enough of this before I fall foul of the Equal-Respect-For-
Std_logic_unsigned-Users political correctness police.

>For testbenches, where one needs to add to the address as part
>of the algorithm, what do you do? Note that address is only a
>collection of bits and, hence, is std_logic_vector.

Indeed. But I suggest that it should be a collection of bits
ONLY at the level of a BFM that's tying the (more abstract)
testbench to the DUT and its life-support systems.
Inside the testbench, where our reference model for
the address-manipulating algorithm exists, the address
is (I hope) most definitely NOT represented as a
std_logic_vector. Instead I hope that I have some
sensible data structure (record) capturing a fairly
abstract view of the transaction that I'm pushing
around the testbench. Inside that record, the address
may well be represented as an integer - or something
quite else. The representation, I hope, is fairly well
hidden behind various access and manipulation
procedures that work on variables of this record type.

That kind of structuring gets me some way towards
an object-oriented view of the testbench - OK, the
syntax isn't as pretty as it would be in a proper OO
language, and inheritance isn't a serious proposition,
but I can make information-hiding work bearably well.
If some of my access procedures need to do fiddly
type conversions, so be it - I write them once only.

> Methodology wise, is it ok to use a different data type in the
> testbench just because you want to do math?

Absolutely. I want my TB to look as much like software
as I can possibly make it. I want to throw transaction
records to and fro across the boundary between a rather
abstract TB and a collection of BFMs that do the dirty work
of translating between abstract records and concrete
bit patterns. Sadly that's tougher in VHDL than in
Verilog because I can't call a (BFM) procedure in one
instance from a process in a different instance, but
by sensible use of record ports and handshaking
procedures I can make it all manageable.

By the way, this has long been by far the top of
my VHDL wish-list: something like the Ada
rendezvous mechanism, or 'e' method
ports, allowing me to call a procedure from
out-of-module.

> 3) Use std_logic_unsigned:
> address <= address + 1 ;
>
> Your friend ;)

I can choose my friends, but I can't easily choose my
prejudices :-)

>OTOH, in RTL code if you don't use std_logic_unsigned and
>you are accustomed to writing:
> if unsigned(Address) > "01001" then
>
> What happens if you forget the type conversion:
> if Address > "01001" then
>
> Yikes - both of these compile, however, if Address is not
> 5 bits this is a potential bug.

Yikes indeed. But numeric_std beautifully rescues us from
this by allowing comparison between unsigned and integer.
I would *always* regard magnitude comparison with a
vector literal as being questionable style - there are too
many things that can go wrong, as you say.

>My point being that this is not as crystal clear problem as
>many wish it to be.

Sure; and, of course, if you're bilingual in VHDL and
Verilog the crystal is even foggier, because so many
of the key methodology decisions are likely to go
different ways in the two languages.

>Jim
>VHDL Evangelist

Nice. However, even VHDL Evangelists have to admit
that SystemVerilog packed unions are pretty cool and
make it rather easy to solve some of these problems :-)
--
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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

Re: undeclared identifier error message but all libraries are declaredand added (precision)
 

Jonathan,
> By the way, this has long been by far the top of
> my VHDL wish-list: something like the Ada
> rendezvous mechanism, or

There is some work being considered, but it would not
hurt to have additional perspectives.

Put together a proposal and submit it at:
http://www.eda.org/vasg/bugrep.htm

> 'e' method ports, allowing me to call a procedure
> from out-of-module.
Don't know e, however, due to driver issues, it would
seem to be challenging to make this more than a procedure
in a package.

> Nice. However, even VHDL Evangelists have to admit
> that SystemVerilog packed unions are pretty cool and
> make it rather easy to solve some of these problems :-)

Perhaps submit Unions too - don't take this as me saying
something nice about that kludge of a language though.

Cheers,
Jim