Integer in port declaration?

Discussion in 'VHDL' started by Lenny, Jul 3, 2007.

  1. Lenny

    Lenny Guest

    Hi all :)

    I'm using Xilinx ISE 8.2 web edition toolsuite and writing the code in
    vhdl language.

    My question is: it's possible to declare an integer in port statement?
    Reading a book (I'm a newbie in vhdl:) it seems to be legal, so I did
    it, but the logic simulation ("Generate Expected Result" in Xilinx ISE
    simulator) showed me an unknown state for this port; the vhdl list is:

    -- NOT_OK code (simple counter)
    entity Tmr1 is
    port(clk, reset: IN std_logic;
    seg1: OUT integer range 0 to 9);
    end Tmr1;

    architecture Behavioral of Tmr1 is
    begin
    process(clk, reset)
    variable un: integer range 0 to 10;
    begin
    if (reset='1') then
    un:=0;
    elsif rising_edge(clk) then
    un:=un+1;
    if un=10 then un:=0;
    end if;
    end if;
    seg1<=un;
    end process;
    end Behavioral;

    -- end NOT_OK code

    Behavioral simulation is OK, but logic simulation shows a strange
    unknown in seg1. Here you could see the simulation:
    http://img112.imageshack.us/my.php?image=simnotokgf8.png

    Using std_logic_vector type intead of integer in port declaration solved
    the problem:

    --OK_CODE (simple counter)
    library IEEE;
    use ieee.std_logic_arith.all;
    use IEEE.STD_LOGIC_1164.ALL;

    entity Tmr1 is
    port(clk, reset: IN std_logic;
    seg1: OUT std_logic_vector(7 downto 0));
    end Tmr1;

    architecture Behavioral of Tmr1 is
    begin
    process(clk, reset)
    variable un: integer range 0 to 10;
    begin
    if (reset='1') then
    un:=0;
    elsif rising_edge(clk) then
    un:=un+1;
    if un=10 then un:=0; end if;
    end if;
    seg1<=conv_std_logic_vector(un,8);
    end process;
    end Behavioral;
    -- End OK_CODE

    Any explaination? Dealing with integers in port statement is not allowed?!?

    Lenny
    Lenny, Jul 3, 2007
    #1
    1. Advertising

  2. Lenny <> writes:

    > Hi all :)
    >
    > I'm using Xilinx ISE 8.2 web edition toolsuite and writing the code in
    > vhdl language.
    >
    > My question is: it's possible to declare an integer in port statement?
    > Reading a book (I'm a newbie in vhdl:) it seems to be legal, so I did
    > it, but the logic simulation ("Generate Expected Result" in Xilinx ISE
    > simulator) showed me an unknown state for this port; the vhdl list is:
    >


    It's OK to use integers and other non-logic types in *internal*
    entities, but if you use them on the top-level entity to represent
    actual device pins, the tools will turn them into std_logic_vectors,
    and then when you run the "logic simulation" (I'm not familiar with
    ISE's simulator, but that sounds like a gate-level simulation?), you
    find they don't match any more.

    Feel free to use integers inside the FPGA, but convert them to
    std_logic_vectors "at the pins", as you've discovered:

    I see you've used std_logic_arith below, you're better off with
    numeric_std (search the archives, there's many threads on this!)

    <snip NOT OK code>

    > Behavioral simulation is OK, but logic simulation shows a strange
    > unknown in seg1. Here you could see the simulation:
    > http://img112.imageshack.us/my.php?image=simnotokgf8.png
    >
    > Using std_logic_vector type intead of integer in port declaration solved
    > the problem:
    >


    Yes.

    > --OK_CODE (simple counter)
    > library IEEE;
    > use ieee.std_logic_arith.all;


    Don't use std_logic_arith it's non-standard (even though the
    "ieee." implies it is!) - search the archives or the VHDL FAQ for
    more details.

    Do this instead:
    use ieee.numeric_std.all;
    > use IEEE.STD_LOGIC_1164.ALL;
    >
    > entity Tmr1 is
    > port(clk, reset: IN std_logic;
    > seg1: OUT std_logic_vector(7 downto 0));
    > end Tmr1;
    >
    > architecture Behavioral of Tmr1 is
    > begin
    > process(clk, reset)
    > variable un: integer range 0 to 10;
    > begin
    > if (reset='1') then
    > un:=0;
    > elsif rising_edge(clk) then
    > un:=un+1;
    > if un=10 then un:=0; end if;
    > end if;
    > -- not this seg1<=conv_std_logic_vector(un,8);

    And this:
    seg1<=std_logic_vector(to_unsigned(un,seg1'range));
    > end process;
    > end Behavioral;
    > -- End OK_CODE
    >
    > Any explaination? Dealing with integers in port statement is not allowed?!?
    >


    Not on the pins :)

    HTH!

    Martin

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.net/electronics.html
    Martin Thompson, Jul 3, 2007
    #2
    1. Advertising

  3. Lenny

    KJ Guest

    "Lenny" <> wrote in message
    news:4689f3b0$0$17944$...
    > Hi all :)
    >
    > I'm using Xilinx ISE 8.2 web edition toolsuite and writing the code in
    > vhdl language.
    >
    > My question is: it's possible to declare an integer in port statement?
    > Reading a book (I'm a newbie in vhdl:) it seems to be legal, so I did
    > it, but the logic simulation ("Generate Expected Result" in Xilinx ISE
    > simulator) showed me an unknown state for this port; the vhdl list is:
    >


    It looks like this is a bug in ISE. Looking at the waveforms, ISE created a
    10 bit vector instead of a 4 bit to represent the integer (bug 1). Then it
    started incrementing the most significant bit instead of the least (bug
    2...or maybe the X folks simply like to count that way). Then when it
    couldn't count beyond 1 it went unknown (bug 3).

    The interesting thing is that it must've kept counting somewhat correctly
    since every 10th clock cycle seg1 went back to 0, then 1, then unknown. It
    could be that ISE fumbled somewhat with handling variables (try changing
    'un' from a variable to a signal and see if you get the same result).
    Another thing that might've confused it is the integer range on 'seg1' is 0
    to 9, but 'un' is 0 to 10 (try rewriting so that they both have the same
    range).

    Although perfectly legit, using anything other than
    std_logic/std_ulogic/std_logic_vector/std_ulogic_vector at the top level of
    the design is generally discouraged. One reason is that it creates an
    inconsistency in the basic data type (i.e. std_logic_vector or integer) for
    the unit under test in a testbench. The main reason though is that the
    synthesis vendors sometimes do a poor job of supporting the language and you
    need to stoop to their level to get your job done. One out here is to
    switch to another vendor (i.e. Altera, Lattice, etc.) and let the other guys
    know why you won't be using their parts.

    Your code is fine as is, decide whether using brand X is worth the hassles
    on something this simple or not.

    KJ
    KJ, Jul 3, 2007
    #3
  4. Lenny

    Guest

    KJ,

    Why do you think this is a bug?
    It's all a matter of encoding and representation. You can represent an
    integer with whatever code you can think of. Sure it is recommended by
    IEEE 1076.6 that a synthesis tool converts integers into a
    corresponding vector of bits and should have an unsigned binary
    representation.
    But it is not a bug doing it in another way.

    Kind regards,

    Yves

    On 3 jul, 12:13, "KJ" <> wrote:
    > "Lenny" <> wrote in message
    >
    > news:4689f3b0$0$17944$...
    >
    > > Hi all :)

    >
    > > I'm using Xilinx ISE 8.2 web edition toolsuite and writing the code in
    > > vhdl language.

    >
    > > My question is: it's possible to declare an integer in port statement?
    > > Reading a book (I'm a newbie in vhdl:) it seems to be legal, so I did
    > > it, but the logic simulation ("Generate Expected Result" in Xilinx ISE
    > > simulator) showed me an unknown state for this port; the vhdl list is:

    >
    > It looks like this is a bug in ISE. Looking at the waveforms, ISE created a
    > 10 bit vector instead of a 4 bit to represent the integer (bug 1). Then it
    > started incrementing the most significant bit instead of the least (bug
    > 2...or maybe the X folks simply like to count that way). Then when it
    > couldn't count beyond 1 it went unknown (bug 3).
    >
    > The interesting thing is that it must've kept counting somewhat correctly
    > since every 10th clock cycle seg1 went back to 0, then 1, then unknown. It
    > could be that ISE fumbled somewhat with handling variables (try changing
    > 'un' from a variable to a signal and see if you get the same result).
    > Another thing that might've confused it is the integer range on 'seg1' is 0
    > to 9, but 'un' is 0 to 10 (try rewriting so that they both have the same
    > range).
    >
    > Although perfectly legit, using anything other than
    > std_logic/std_ulogic/std_logic_vector/std_ulogic_vector at the top level of
    > the design is generally discouraged. One reason is that it creates an
    > inconsistency in the basic data type (i.e. std_logic_vector or integer) for
    > the unit under test in a testbench. The main reason though is that the
    > synthesis vendors sometimes do a poor job of supporting the language and you
    > need to stoop to their level to get your job done. One out here is to
    > switch to another vendor (i.e. Altera, Lattice, etc.) and let the other guys
    > know why you won't be using their parts.
    >
    > Your code is fine as is, decide whether using brand X is worth the hassles
    > on something this simple or not.
    >
    > KJ
    , Jul 3, 2007
    #4
  5. Lenny

    Guest

    KJ,

    Why do you think this is a bug?
    It's all a matter of encoding and representation. You can represent an
    integer with whatever code you can think of. Sure it is recommended by
    IEEE 1076.6 that a synthesis tool converts integers into a
    corresponding vector of bits and should have an unsigned binary
    representation.
    But it is not a bug doing it in another way.

    Kind regards,

    Yves

    On 3 jul, 12:13, "KJ" <> wrote:
    > "Lenny" <> wrote in message
    >
    > news:4689f3b0$0$17944$...
    >
    > > Hi all :)

    >
    > > I'm using Xilinx ISE 8.2 web edition toolsuite and writing the code in
    > > vhdl language.

    >
    > > My question is: it's possible to declare an integer in port statement?
    > > Reading a book (I'm a newbie in vhdl:) it seems to be legal, so I did
    > > it, but the logic simulation ("Generate Expected Result" in Xilinx ISE
    > > simulator) showed me an unknown state for this port; the vhdl list is:

    >
    > It looks like this is a bug in ISE. Looking at the waveforms, ISE created a
    > 10 bit vector instead of a 4 bit to represent the integer (bug 1). Then it
    > started incrementing the most significant bit instead of the least (bug
    > 2...or maybe the X folks simply like to count that way). Then when it
    > couldn't count beyond 1 it went unknown (bug 3).
    >
    > The interesting thing is that it must've kept counting somewhat correctly
    > since every 10th clock cycle seg1 went back to 0, then 1, then unknown. It
    > could be that ISE fumbled somewhat with handling variables (try changing
    > 'un' from a variable to a signal and see if you get the same result).
    > Another thing that might've confused it is the integer range on 'seg1' is 0
    > to 9, but 'un' is 0 to 10 (try rewriting so that they both have the same
    > range).
    >
    > Although perfectly legit, using anything other than
    > std_logic/std_ulogic/std_logic_vector/std_ulogic_vector at the top level of
    > the design is generally discouraged. One reason is that it creates an
    > inconsistency in the basic data type (i.e. std_logic_vector or integer) for
    > the unit under test in a testbench. The main reason though is that the
    > synthesis vendors sometimes do a poor job of supporting the language and you
    > need to stoop to their level to get your job done. One out here is to
    > switch to another vendor (i.e. Altera, Lattice, etc.) and let the other guys
    > know why you won't be using their parts.
    >
    > Your code is fine as is, decide whether using brand X is worth the hassles
    > on something this simple or not.
    >
    > KJ
    , Jul 3, 2007
    #5
  6. Lenny

    KJ Guest

    On Jul 3, 9:07 am, "" <>
    wrote:
    > KJ,
    >
    > Why do you think this is a bug?
    > It's all a matter of encoding and representation. You can represent an
    > integer with whatever code you can think of. Sure it is recommended by
    > IEEE 1076.6 that a synthesis tool converts integers into a
    > corresponding vector of bits and should have an unsigned binary
    > representation.
    > But it is not a bug doing it in another way.
    >
    > Kind regards,
    >
    > Yves

    OK, it's a possible then...while it's easy to say that the tools 'can'
    represent integers in whatever way they prefer, one can also say that
    a given tool will represent integer in a single particular way and if
    it does not represent them in that fashion under certain conditions
    then it's a bug.

    So, if there is some ISE documentation that defines how integers are
    represented and it does not agree with what the original poster
    showed, then it is a bug. If ISE chooses to represent integers in the
    sort of 'one-hot' fashion that it appears to be then it's not a
    bug....but certainly a feature that one would need to have control
    over. The appearance is that an integer in the range from 'a' to 'b'
    would likely result in a std_logic_vector(a to b). Anyone know if
    that is what ISE actually does?

    KJ
    KJ, Jul 3, 2007
    #6
  7. wrote:

    > Why do you think this is a bug?
    > It's all a matter of encoding and representation. You can represent an
    > integer with whatever code you can think of. Sure it is recommended by
    > IEEE 1076.6 that a synthesis tool converts integers into a
    > corresponding vector of bits and should have an unsigned binary
    > representation.
    > But it is not a bug doing it in another way.


    One-hot encoding would be valid, but something else is going on.
    The count has only two values.

    John:
    ISE comes with an oem version of modelsim.
    Try that on the gate netlist.

    -- Mike Treseler
    Mike Treseler, Jul 3, 2007
    #7
  8. Mike Treseler wrote:

    > One-hot encoding would be valid, but something else is going on.
    > The count has only two values.

    three
    >
    Mike Treseler, Jul 3, 2007
    #8
  9. Lenny

    Guest

    On 3 jul, 15:42, KJ <> wrote:
    > On Jul 3, 9:07 am, "" <>
    > wrote:> KJ,
    >
    > > Why do you think this is a bug?
    > > It's all a matter of encoding and representation. You can represent an
    > > integer with whatever code you can think of. Sure it is recommended by
    > > IEEE 1076.6 that a synthesis tool converts integers into a
    > > corresponding vector of bits and should have an unsigned binary
    > > representation.
    > > But it is not a bug doing it in another way.

    >
    > > Kind regards,

    >
    > > Yves

    >
    > OK, it's a possible then...while it's easy to say that the tools 'can'
    > represent integers in whatever way they prefer, one can also say that
    > a given tool will represent integer in a single particular way and if
    > it does not represent them in that fashion under certain conditions
    > then it's a bug.
    >
    > So, if there is some ISE documentation that defines how integers are
    > represented and it does not agree with what the original poster
    > showed, then it is a bug. If ISE chooses to represent integers in the
    > sort of 'one-hot' fashion that it appears to be then it's not a
    > bug....but certainly a feature that one would need to have control
    > over. The appearance is that an integer in the range from 'a' to 'b'
    > would likely result in a std_logic_vector(a to b). Anyone know if
    > that is what ISE actually does?
    >
    > KJ


    Why would a tool need to represent integers always in the same
    fashion?
    Do you always want an integer to be encoded in the same way?
    I actually don't care how it is being encoded, as long as the
    resulting circuit is operating as I want it to operate within spec.
    If the synthesis tool instantiates a 4 bit counter, or a 10 bit
    register, is all the same, but it might very much affect the
    performance of the circuit how it is implemented.

    If you on the other hand want to get an integer on a toplevel port,
    then I would convert it to an unsigned or a std_logic_vector, so that
    I know the exact representation of each number.

    Regards,

    Yves
    , Jul 4, 2007
    #9
  10. Lenny

    KJ Guest

    <> wrote in message
    news:...
    > On 3 jul, 15:42, KJ <> wrote:
    >> On Jul 3, 9:07 am, "" <>
    >> wrote:> KJ,

    <snip>
    >> So, if there is some ISE documentation that defines how integers are
    >> represented and it does not agree with what the original poster
    >> showed, then it is a bug. If ISE chooses to represent integers in the
    >> sort of 'one-hot' fashion that it appears to be then it's not a
    >> bug....but certainly a feature that one would need to have control
    >> over. The appearance is that an integer in the range from 'a' to 'b'
    >> would likely result in a std_logic_vector(a to b). Anyone know if
    >> that is what ISE actually does?
    >>
    >> KJ

    >
    > Why would a tool need to represent integers always in the same
    > fashion?

    If the documentation said it represents integers in only one way. I don't
    know what the ISE documentation has to say about how it represents integers,
    if it uses only one form or multiple forms.

    > Do you always want an integer to be encoded in the same way?

    What I would want is for the documentation to reflect how integers are
    encoded so that if I had a need to know how it is encoded then I would have
    it.

    > I actually don't care how it is being encoded,

    And most of the time, I wouldn't care either

    > as long as the
    > resulting circuit is operating as I want it to operate within spec.

    But what if it doesn't?

    > If the synthesis tool instantiates a 4 bit counter, or a 10 bit
    > register, is all the same, but it might very much affect the
    > performance of the circuit how it is implemented.

    And if performance is a problem, now suddenly you might be concerned about
    how integers get represented within the tool and would like (and rightly
    expect) the documentation to reflect how it is encoded so perhaps you could
    do something about it. Making the assumption that nobody ever needs to know
    how things get encoded while true in many cases, in others it is not.

    >
    > If you on the other hand want to get an integer on a toplevel port,
    > then I would convert it to an unsigned or a std_logic_vector, so that
    > I know the exact representation of each number.
    >

    And that is a part of the reason why std_logic/std_ulogic and their vector
    formats are the preferred types for top level interfaces. Preferred though
    does not imply that that is the only legal format.

    I don't think we're disagreeing that ISE can represent integers in whatever
    fashion they so choose and still adhere to the language standard, all I've
    been saying from the start is that the representation of an integer at the
    top level should be consistent with the ISE documentation for how integers
    are represented...otherwise it's a bug in ISE regardless of whether you
    could (or should) have converted those integers to unsigned or
    std_logic_vector.

    In any case, none of this has to do with the original poster's real issue
    about why the counter doesn't count when integers are brought out to the top
    level.

    KJ
    KJ, Jul 4, 2007
    #10
    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. Noah
    Replies:
    5
    Views:
    948
  2. Alex Vinokur
    Replies:
    4
    Views:
    574
    Jonathan Turkanis
    Apr 5, 2004
  3. Ovidesvideo
    Replies:
    4
    Views:
    486
    Andrey Tarasevich
    Dec 10, 2004
  4. kelvSYC
    Replies:
    6
    Views:
    7,215
    Richard Herring
    May 17, 2005
  5. Merciadri Luca
    Replies:
    2
    Views:
    971
    Merciadri Luca
    Nov 2, 2010
Loading...

Share This Page