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

Discussion in 'VHDL' started by yttrium, Jan 1, 2007.

  1. yttrium

    yttrium Guest

    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
     
    yttrium, Jan 1, 2007
    #1
    1. Advertising

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

    On Mon, 01 Jan 2007 18:48:00 +0100, yttrium
    <> 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

    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, Jan 1, 2007
    #2
    1. Advertising

  3. yttrium

    yttrium Guest

    Jonathan Bromley wrote:
    > On Mon, 01 Jan 2007 18:48:00 +0100, yttrium
    > <> 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
     
    yttrium, Jan 1, 2007
    #3
  4. yttrium

    Jim Lewis Guest

    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
     
    Jim Lewis, Jan 2, 2007
    #4
  5. Re: undeclared identifier error message but all libraries are declared and added (precision)

    On Mon, 01 Jan 2007 23:49:51 +0100, yttrium
    <> 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

    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, Jan 2, 2007
    #5
  6. yttrium

    yttrium Guest

    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, Jan 2, 2007
    #6
  7. yttrium

    yttrium Guest

    Jonathan Bromley wrote:
    > On Mon, 01 Jan 2007 23:49:51 +0100, yttrium
    > <> 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
     
    yttrium, Jan 2, 2007
    #7
  8. yttrium

    Jim Lewis Guest

    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
     
    Jim Lewis, Jan 2, 2007
    #8
  9. Re: undeclared identifier error message but all libraries are declared and added (precision)

    On Tue, 02 Jan 2007 08:26:20 -0800, Jim Lewis
    <> 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

    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, Jan 2, 2007
    #9
  10. yttrium

    Jim Lewis Guest

    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
     
    Jim Lewis, Jan 2, 2007
    #10
  11. yttrium

    Jan Decaluwe Guest

    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
     
    Jan Decaluwe, Jan 3, 2007
    #11
  12. yttrium

    KJ Guest

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

    "Jan Decaluwe" <> wrote in message
    news:...
    > 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
     
    KJ, Jan 5, 2007
    #12
  13. Re: undeclared identifier error message but all libraries are declared and added (precision)

    On Fri, 05 Jan 2007 12:05:58 GMT, "KJ"
    <> wrote:

    >- Lack of something equivalent to a C++ template. [...]
    >
    >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

    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, Jan 5, 2007
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ron Natalie

    Re: undeclared identifier?

    Ron Natalie, Jul 21, 2003, in forum: C++
    Replies:
    0
    Views:
    424
    Ron Natalie
    Jul 21, 2003
  2. craigbeanhead
    Replies:
    6
    Views:
    542
    Jack Klein
    Jul 27, 2003
  3. craigbeanhead
    Replies:
    1
    Views:
    409
    Eric Sosman
    Jul 24, 2003
  4. Replies:
    2
    Views:
    1,782
  5. Kensai
    Replies:
    6
    Views:
    746
    Victor Bazarov
    Dec 18, 2009
Loading...

Share This Page