undeclared identifier error message but all libraries are de

[yttrium]

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

 

[Jonathan Bromley]

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.

 

[yttrium]

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

 

[Jan Decaluwe]

Jim Lewis wrote:

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 think this demonstrates the basic problem: we hardware designers
tend to think bottom-up, instead of top-down.

From a high-level perspective, what could be more integer-like
than an address (even without adding something to it)? Why would
I have to look at it as a collection of bits, especially in
a test bench, but also in RTL?

Still, most of us insist in dealing with integer representations
(unsigned, signed, overloaded std_logic_vectors) instead of the
abstract type itself. Problem is, people are very bad at that, even
hardware designers. So we get into trouble with it all the time.

For example, in a language like VHDL, the combination of
representational types with strong typing leads to an
explosion of type conversion and overloaded functions.
VHDL designers tend to think that this is a normal and
even useful (?) consequence of strong typing. But that's not
the case. Rather, it shows that we're not using the
"right" types - or that those are not available.

Regards,

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com

 

[KJ]

"Jan Decaluwe" <jan@jandecaluwe.com> wrote in message
news:459BD211.9090004@jandecaluwe.com...

Jim Lewis wrote:

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 think this demonstrates the basic problem: we hardware designers
tend to think bottom-up, instead of top-down.

From a high-level perspective, what could be more integer-like
than an address (even without adding something to it)? Why would
I have to look at it as a collection of bits, especially in
a test bench, but also in RTL?

Still, most of us insist in dealing with integer representations
(unsigned, signed, overloaded std_logic_vectors) instead of the
abstract type itself. Problem is, people are very bad at that, even
hardware designers. So we get into trouble with it all the time.

For example, in a language like VHDL, the combination of
representational types with strong typing leads to an
explosion of type conversion and overloaded functions.
VHDL designers tend to think that this is a normal and
even useful (?) consequence of strong typing. But that's not
the case. Rather, it shows that we're not using the
"right" types - or that those are not available.

Although not using the 'right' types does lead to type conversion functions
there are still other areas where the type conversions will come up that
don't have anything to do with bottom-up or top-down approaches.

- Generally things need to be coded to a specification and that
specification specifies bit locations for fields in ports that interface to
software. If the hardware design were done in SystemC and the software in
C++ then one could dispense with the software interface portion of the
specification document and instead reference it to a C header file which
links to both the software and the hardware design so that changes to the
header will be incorporated in the next build of both. Lacking such a
monolithic approach you pretty much have to have conversion functions
somewhere to put port fields into the proper bit positions.

- System issues. What does it mean to update a particular byte of a
natural? That can only take on meaning after one performs the conversion to
bits and vectors. Not having a way to update a particular subunit of some
software port forces one to instead define all operations to be on things of
a particular data width. So of course you pick the size most convenient for
the design at hand and choose 8, 16, 32 based on the processor that you're
using in this system and move on.....and then find that code not really
reusable when you'd like to reuse that code in a design that has a processor
with a different native data size.

- Lack of something equivalent to a C++ template. When creating reusable
IP, generally the 'std_logic' type and derived types are used as the
interface because there is no way to make the function portable to arbitrary
types which creates the need for type conversion functions to get you to and
from the std_logic types.

As a simple example take the classic single clock fifo. Once you've written
the code for such a fifo to handle let's say type 'std_ulogic_vector' you
can't directly reuse that design to create a fifo to handle type 'natural'
(or any other type for that matter). Instead you have to physically copy
the design and dutifully go through and change the 'std_ulogic_vector' to
'natural' where it refers to fifo data items throughout the code. That copy
operation though has just created a new independent code stream.
Fixes/changes to the 'std_ulogic' version do not get incorporated in the
'natural' version unless you do so manually. The only approach in VHDL to
maintain the single code stream for the fifo functionality then is to create
conversion functions that translate from the newly desird type (in this case
'natural') to/from the type handled by the fifo design (in this case
std_ulogic_vector). Thus the conversion functions provide an aid to
actually being able to reuse IP.....but the only reason for needing those
functions is because VHDL does not have a way to parameterize the actual
type of a signal as you can with a C++ template.

Another approach would be to use some form of meta-language where the
'pristine' design code for the functionality with parameterizable data type
is coded and some tool is then used to spit out VHDL (or any other language)
as output. But the only reason for the meta-language is because of the lack
of features in the original language....it's much like a translator that
reads in System C code and spits out VHDL/Verilog for synthesis. Some
companies use this approach simply as a method to be able to supply code in
a particular language to meet customer requirements that may state use of a
preferred language.

Kevin Jennings

 

[Jonathan Bromley]

On Fri, 05 Jan 2007 12:05:58 GMT, "KJ"
<kkjennings@sbcglobal.net> wrote:

As a simple example take the classic single clock fifo. Once you've written
the code for such a fifo to handle let's say type 'std_ulogic_vector' you
can't directly reuse that design to create a fifo to handle type 'natural'
(or any other type for that matter).

SystemVerilog has addressed this with its type parameters.
As well as being useful for making templated classes, it allows any
design that only moves and stores data to be parameterized for type.

I know I have to say this quietly when Jim Lewis is listening ,
but that is one of the really good contributions that
SystemVerilog has made to the world of RTL design.
--
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.

 

[Jim Lewis]

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

 

[Jonathan Bromley]

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.

 

[yttrium]

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

 

[yttrium]

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

 

[Jim Lewis]

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

 

[Jonathan Bromley]

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.

 

[Jim Lewis]

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