short integer equivalent

Discussion in 'VHDL' started by mk.supriya@gmail.com, Jul 31, 2007.

  1. Guest

    hello,
    can anybody tell me what data type i should use to reduce the size of
    integer to 2 bytes instead of 4?
    i.e is there something analogues with short int?
     
    , Jul 31, 2007
    #1
    1. Advertising

  2. wrote:
    > hello,
    > can anybody tell me what data type i should use to reduce the size of
    > integer to 2 bytes instead of 4?
    > i.e is there something analogues with short int?


    numeric_std.unsigned(15 downto 0)

    -- Mike Treseler
     
    Mike Treseler, Jul 31, 2007
    #2
    1. Advertising

  3. ast Guest

    <> a écrit dans le message de news: ...
    > hello,
    > can anybody tell me what data type i should use to reduce the size of
    > integer to 2 bytes instead of 4?
    > i.e is there something analogues with short int?
    >


    integer range 0 to 65535
     
    ast, Jul 31, 2007
    #3
  4. Shannon Guest

    On Jul 31, 8:22 am, Mike Treseler <> wrote:
    > wrote:
    > > hello,
    > > can anybody tell me what data type i should use to reduce the size of
    > > integer to 2 bytes instead of 4?
    > > i.e is there something analogues with short int?

    >
    > numeric_std.unsigned(15 downto 0)
    >
    > -- Mike Treseler


    I trust your answer Mike. What would INTEGER RANGE 0 TO 65535 do?

    Shannon
     
    Shannon, Jul 31, 2007
    #4
  5. Andy Guest

    On Jul 31, 11:58 am, Shannon <> wrote:
    > On Jul 31, 8:22 am, Mike Treseler <> wrote:
    >
    > > wrote:
    > > > hello,
    > > > can anybody tell me what data type i should use to reduce the size of
    > > > integer to 2 bytes instead of 4?
    > > > i.e is there something analogues with short int?

    >
    > > numeric_std.unsigned(15 downto 0)

    >
    > > -- Mike Treseler

    >
    > I trust your answer Mike. What would INTEGER RANGE 0 TO 65535 do?
    >
    > Shannon


    Same thing, and simulate faster too, assuming you wanted an unsigned,
    16 bit representation.

    Otherwise, "integer range -(2**15) to 2**15-1" would give you a
    signed, 16 bit representation.

    Andy
     
    Andy, Jul 31, 2007
    #5
  6. On Tue, 31 Jul 2007 16:58:38 -0000,
    Shannon <> wrote:

    >> > i.e is there something analogues with short int?

    >>
    >> numeric_std.unsigned(15 downto 0)
    >>
    >> -- Mike Treseler

    >
    >I trust your answer Mike. What would INTEGER RANGE 0 TO 65535 do?


    As Andy said, it would give you a 16-bit unsigned integer.

    You can represent anything <= 31 bits in VHDL by using a suitable
    integer SUBTYPE. 32 bits is somewhat doubtful, because the
    VHDL language standard does not require implementations to
    handle the most negative twos complement value -(2**31)
    (usually represented as 16#8000_0000#). And anything wider
    than 32 bits is unlikely to work with integer subtypes.

    So, here are the tradeoffs that I perceive between using
    integer subtypes vs. UNSIGNED/SIGNED vectors from numeric_std:

    Benefits of vector types
    ~~~~~~~~~~~~~~~~~~~~~~~~
    * Any reasonable bit width is OK - not limited to 31/32 bits,
    and (in particular) 32-bit unsigned is easy and reliable
    * Trivially easy conversion to/from std_logic_vector
    * Trivially easy bit-picking, slicing, logic (AND/OR) operations
    * Fuss-free wraparound modulo 2**N (e.g. 8-bit counter contains
    255, increment it, 255+1=0 just like real hardware)
    * Unknown, uninitialized and tri-state values can be handled

    Benefits of integer subtypes
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    * Faster simulation (even in simulators that have accelerated
    implementations of numeric_std)
    * Trivially easy arithmetic between signed and unsigned values
    * Run-time detection of integer overflow in simulation
    * Trivially easy to capture the carry output from +/-
    * You can assign numeric constants to them directly

    Significant drawbacks of vector types
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    * Can't directly assign numeric values to them
    * Unsigned vs. signed arithmetic is tricky
    * Capturing carry/overflow bits from an arithmetic
    operation requires some care

    Significant drawbacks of integer subtypes
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    * Anything >=32 bits is unreliable and/or broken
    * Messy conversion to/from std_logic_vector (though you
    can easily sugar-coat it with custom functions)
    * Modelling modulo-2**N wraparound behaviour is tricky
    * Bitwise masking and logic is hopelessly messy

    My personal preference has been strongly in favour of
    the numeric_std vector types for many years now, primarily
    because of the problem with representing unsigned 32-bit
    integers using the integer types in VHDL. Others
    have taken the opposite stance. Make up your own mind -
    but please do it on the basis of reasoned evaluation
    rather than guesswork. I make heavy use of integer
    types in VHDL when it serves my purposes, especially
    in testbench code.

    I'd be delighted if anyone else could add to this
    pro/con checklist.
    --
    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, Jul 31, 2007
    #6
  7. Andy Guest

    On Jul 31, 2:34 pm, Jonathan Bromley <>
    wrote:
    > On Tue, 31 Jul 2007 16:58:38 -0000,
    >
    > Shannon <> wrote:
    > >> > i.e is there something analogues with short int?

    >
    > >> numeric_std.unsigned(15 downto 0)

    >
    > >> -- Mike Treseler

    >
    > >I trust your answer Mike. What would INTEGER RANGE 0 TO 65535 do?

    >
    > As Andy said, it would give you a 16-bit unsigned integer.
    >
    > You can represent anything <= 31 bits in VHDL by using a suitable
    > integer SUBTYPE. 32 bits is somewhat doubtful, because the
    > VHDL language standard does not require implementations to
    > handle the most negative twos complement value -(2**31)
    > (usually represented as 16#8000_0000#). And anything wider
    > than 32 bits is unlikely to work with integer subtypes.
    >
    > So, here are the tradeoffs that I perceive between using
    > integer subtypes vs. UNSIGNED/SIGNED vectors from numeric_std:
    >
    > Benefits of vector types
    > ~~~~~~~~~~~~~~~~~~~~~~~~
    > * Any reasonable bit width is OK - not limited to 31/32 bits,
    > and (in particular) 32-bit unsigned is easy and reliable
    > * Trivially easy conversion to/from std_logic_vector
    > * Trivially easy bit-picking, slicing, logic (AND/OR) operations
    > * Fuss-free wraparound modulo 2**N (e.g. 8-bit counter contains
    > 255, increment it, 255+1=0 just like real hardware)
    > * Unknown, uninitialized and tri-state values can be handled
    >
    > Benefits of integer subtypes
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > * Faster simulation (even in simulators that have accelerated
    > implementations of numeric_std)
    > * Trivially easy arithmetic between signed and unsigned values
    > * Run-time detection of integer overflow in simulation
    > * Trivially easy to capture the carry output from +/-
    > * You can assign numeric constants to them directly
    >
    > Significant drawbacks of vector types
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > * Can't directly assign numeric values to them
    > * Unsigned vs. signed arithmetic is tricky
    > * Capturing carry/overflow bits from an arithmetic
    > operation requires some care
    >
    > Significant drawbacks of integer subtypes
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > * Anything >=32 bits is unreliable and/or broken
    > * Messy conversion to/from std_logic_vector (though you
    > can easily sugar-coat it with custom functions)
    > * Modelling modulo-2**N wraparound behaviour is tricky
    > * Bitwise masking and logic is hopelessly messy
    >
    > My personal preference has been strongly in favour of
    > the numeric_std vector types for many years now, primarily
    > because of the problem with representing unsigned 32-bit
    > integers using the integer types in VHDL. Others
    > have taken the opposite stance. Make up your own mind -
    > but please do it on the basis of reasoned evaluation
    > rather than guesswork. I make heavy use of integer
    > types in VHDL when it serves my purposes, especially
    > in testbench code.
    >
    > I'd be delighted if anyone else could add to this
    > pro/con checklist.
    > --
    > 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
    > ://www.MYCOMPANY.com
    >
    > The contents of this message may contain personal views which
    > are not the views of Doulos Ltd., unless specifically stated.


    Wow, that's a pretty good summary of pro's and con's.

    However, if a conversion between integer and std_logic_vector is
    "messy", it should at least be noted that a slightly less messy
    conversion is also required between signed/unsigned and
    std_logic_vector.

    Also, the same condition of not using custom functions (or overridden
    operators) for bitwise functions on integers should be stated. I have
    package of bitwise logical operators for naturals that I use that
    converts them to numeric_bit.unsigned(30 downto 0) and back, but you
    have to be careful to modulo the results of some operators (i.e. NOT,
    NOR, etc.) before assignment to anything less than a 31 bit natural.
    Likewise, grabbing slices using mod and / is not hard either (though
    harder than vectors).

    Other advantages of integers: Changing "sizes" in assignments is
    transparent. Integers can be used directly to index an array, and they
    allow use of numeric constants as target expressions in case
    statements.

    Finaly, (my_integer + 1 > my_integer) is always true, else it will die
    trying (assertion)! I don't consider mimicking the hardware
    inaccuracies of (my_vector + 1) to be an advantage. :^)

    Andy
     
    Andy, Jul 31, 2007
    #7
  8. Guest

    On Aug 1, 3:52 am, Andy <> wrote:
    > On Jul 31, 2:34 pm, Jonathan Bromley <>
    > wrote:
    >
    >
    >
    >
    >
    > > On Tue, 31 Jul 2007 16:58:38 -0000,

    >
    > > Shannon <> wrote:
    > > >> > i.e is there something analogues with short int?

    >
    > > >> numeric_std.unsigned(15 downto 0)

    >
    > > >> -- Mike Treseler

    >
    > > >I trust your answer Mike. What would INTEGER RANGE 0 TO 65535 do?

    >
    > > As Andy said, it would give you a 16-bit unsigned integer.

    >
    > > You can represent anything <= 31 bits in VHDL by using a suitable
    > > integer SUBTYPE. 32 bits is somewhat doubtful, because the
    > > VHDL language standard does not require implementations to
    > > handle the most negative twos complement value -(2**31)
    > > (usually represented as 16#8000_0000#). And anything wider
    > > than 32 bits is unlikely to work with integer subtypes.

    >
    > > So, here are the tradeoffs that I perceive between using
    > > integer subtypes vs. UNSIGNED/SIGNED vectors from numeric_std:

    >
    > > Benefits of vector types
    > > ~~~~~~~~~~~~~~~~~~~~~~~~
    > > * Any reasonable bit width is OK - not limited to 31/32 bits,
    > > and (in particular) 32-bit unsigned is easy and reliable
    > > * Trivially easy conversion to/from std_logic_vector
    > > * Trivially easy bit-picking, slicing, logic (AND/OR) operations
    > > * Fuss-free wraparound modulo 2**N (e.g. 8-bit counter contains
    > > 255, increment it, 255+1=0 just like real hardware)
    > > * Unknown, uninitialized and tri-state values can be handled

    >
    > > Benefits of integer subtypes
    > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > > * Faster simulation (even in simulators that have accelerated
    > > implementations of numeric_std)
    > > * Trivially easy arithmetic between signed and unsigned values
    > > * Run-time detection of integer overflow in simulation
    > > * Trivially easy to capture the carry output from +/-
    > > * You can assign numeric constants to them directly

    >
    > > Significant drawbacks of vector types
    > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > > * Can't directly assign numeric values to them
    > > * Unsigned vs. signed arithmetic is tricky
    > > * Capturing carry/overflow bits from an arithmetic
    > > operation requires some care

    >
    > > Significant drawbacks of integer subtypes
    > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > > * Anything >=32 bits is unreliable and/or broken
    > > * Messy conversion to/from std_logic_vector (though you
    > > can easily sugar-coat it with custom functions)
    > > * Modelling modulo-2**N wraparound behaviour is tricky
    > > * Bitwise masking and logic is hopelessly messy

    >
    > > My personal preference has been strongly in favour of
    > > the numeric_std vector types for many years now, primarily
    > > because of the problem with representing unsigned 32-bit
    > > integers using the integer types in VHDL. Others
    > > have taken the opposite stance. Make up your own mind -
    > > but please do it on the basis of reasoned evaluation
    > > rather than guesswork. I make heavy use of integer
    > > types in VHDL when it serves my purposes, especially
    > > in testbench code.

    >
    > > I'd be delighted if anyone else could add to this
    > > pro/con checklist.
    > > --
    > > 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
    > > ://www.MYCOMPANY.com

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

    >
    > Wow, that's a pretty good summary of pro's and con's.
    >
    > However, if a conversion between integer and std_logic_vector is
    > "messy", it should at least be noted that a slightly less messy
    > conversion is also required between signed/unsigned and
    > std_logic_vector.
    >
    > Also, the same condition of not using custom functions (or overridden
    > operators) for bitwise functions on integers should be stated. I have
    > package of bitwise logical operators for naturals that I use that
    > converts them to numeric_bit.unsigned(30 downto 0) and back, but you
    > have to be careful to modulo the results of some operators (i.e. NOT,
    > NOR, etc.) before assignment to anything less than a 31 bit natural.
    > Likewise, grabbing slices using mod and / is not hard either (though
    > harder than vectors).
    >
    > Other advantages of integers: Changing "sizes" in assignments is
    > transparent. Integers can be used directly to index an array, and they
    > allow use of numeric constants as target expressions in case
    > statements.
    >
    > Finaly, (my_integer + 1 > my_integer) is always true, else it will die
    > trying (assertion)! I don't consider mimicking the hardware
    > inaccuracies of (my_vector + 1) to be an advantage. :^)
    >
    > Andy- Hide quoted text -
    >
    > - Show quoted text -


    thank you all for the reply. simulation is fine, but during synthesis
    if i say just integer it takes a lot of unwanted space, so i will try
    this and see
     
    , Aug 1, 2007
    #8
  9. Andy Guest

    On Aug 1, 2:38 am, wrote:
    > On Aug 1, 3:52 am, Andy <> wrote:
    >
    >
    >
    > > On Jul 31, 2:34 pm, Jonathan Bromley <>
    > > wrote:

    >
    > > > On Tue, 31 Jul 2007 16:58:38 -0000,

    >
    > > > Shannon <> wrote:
    > > > >> > i.e is there something analogues with short int?

    >
    > > > >> numeric_std.unsigned(15 downto 0)

    >
    > > > >> -- Mike Treseler

    >
    > > > >I trust your answer Mike. What would INTEGER RANGE 0 TO 65535 do?

    >
    > > > As Andy said, it would give you a 16-bit unsigned integer.

    >
    > > > You can represent anything <= 31 bits in VHDL by using a suitable
    > > > integer SUBTYPE. 32 bits is somewhat doubtful, because the
    > > > VHDL language standard does not require implementations to
    > > > handle the most negative twos complement value -(2**31)
    > > > (usually represented as 16#8000_0000#). And anything wider
    > > > than 32 bits is unlikely to work with integer subtypes.

    >
    > > > So, here are the tradeoffs that I perceive between using
    > > > integer subtypes vs. UNSIGNED/SIGNED vectors from numeric_std:

    >
    > > > Benefits of vector types
    > > > ~~~~~~~~~~~~~~~~~~~~~~~~
    > > > * Any reasonable bit width is OK - not limited to 31/32 bits,
    > > > and (in particular) 32-bit unsigned is easy and reliable
    > > > * Trivially easy conversion to/from std_logic_vector
    > > > * Trivially easy bit-picking, slicing, logic (AND/OR) operations
    > > > * Fuss-free wraparound modulo 2**N (e.g. 8-bit counter contains
    > > > 255, increment it, 255+1=0 just like real hardware)
    > > > * Unknown, uninitialized and tri-state values can be handled

    >
    > > > Benefits of integer subtypes
    > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > > > * Faster simulation (even in simulators that have accelerated
    > > > implementations of numeric_std)
    > > > * Trivially easy arithmetic between signed and unsigned values
    > > > * Run-time detection of integer overflow in simulation
    > > > * Trivially easy to capture the carry output from +/-
    > > > * You can assign numeric constants to them directly

    >
    > > > Significant drawbacks of vector types
    > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > > > * Can't directly assign numeric values to them
    > > > * Unsigned vs. signed arithmetic is tricky
    > > > * Capturing carry/overflow bits from an arithmetic
    > > > operation requires some care

    >
    > > > Significant drawbacks of integer subtypes
    > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > > > * Anything >=32 bits is unreliable and/or broken
    > > > * Messy conversion to/from std_logic_vector (though you
    > > > can easily sugar-coat it with custom functions)
    > > > * Modelling modulo-2**N wraparound behaviour is tricky
    > > > * Bitwise masking and logic is hopelessly messy

    >
    > > > My personal preference has been strongly in favour of
    > > > the numeric_std vector types for many years now, primarily
    > > > because of the problem with representing unsigned 32-bit
    > > > integers using the integer types in VHDL. Others
    > > > have taken the opposite stance. Make up your own mind -
    > > > but please do it on the basis of reasoned evaluation
    > > > rather than guesswork. I make heavy use of integer
    > > > types in VHDL when it serves my purposes, especially
    > > > in testbench code.

    >
    > > > I'd be delighted if anyone else could add to this
    > > > pro/con checklist.
    > > > --
    > > > 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
    > > > ://www.MYCOMPANY.com

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

    >
    > > Wow, that's a pretty good summary of pro's and con's.

    >
    > > However, if a conversion between integer and std_logic_vector is
    > > "messy", it should at least be noted that a slightly less messy
    > > conversion is also required between signed/unsigned and
    > > std_logic_vector.

    >
    > > Also, the same condition of not using custom functions (or overridden
    > > operators) for bitwise functions on integers should be stated. I have
    > > package of bitwise logical operators for naturals that I use that
    > > converts them to numeric_bit.unsigned(30 downto 0) and back, but you
    > > have to be careful to modulo the results of some operators (i.e. NOT,
    > > NOR, etc.) before assignment to anything less than a 31 bit natural.
    > > Likewise, grabbing slices using mod and / is not hard either (though
    > > harder than vectors).

    >
    > > Other advantages of integers: Changing "sizes" in assignments is
    > > transparent. Integers can be used directly to index an array, and they
    > > allow use of numeric constants as target expressions in case
    > > statements.

    >
    > > Finaly, (my_integer + 1 > my_integer) is always true, else it will die
    > > trying (assertion)! I don't consider mimicking the hardware
    > > inaccuracies of (my_vector + 1) to be an advantage. :^)

    >
    > > Andy- Hide quoted text -

    >
    > > - Show quoted text -

    >
    > thank you all for the reply. simulation is fine, but during synthesis
    > if i say just integer it takes a lot of unwanted space, so i will try
    > this and see


    You need to define your integer signals/variables with a range to
    limit their bit width.

    signal my_int : integer range 0 to 2**bits-1;

    BTW, I thought of another disadvantage to integers: you cannot query
    the range of an integer (or integer subtype) port/signal/variable. For
    example, you can declare my_slv : std_logic_vector(my_port'range) to
    make it the same length as the port; you cannot do that with an
    integer port, you have to pass a generic for this. Or you can use a
    declared subtype, for which you can query the 'high, and 'low
    attributes. I have seen a few instances where optimization resulted in
    pruning integer logic paths down to the size of what they were
    assigned to/from, but it has not been consistent.

    Andy
     
    Andy, Aug 1, 2007
    #9
  10. Various correspondents wrote:

    >>>>>>> i.e is there something analogues with short int?
    >>>>>> numeric_std.unsigned(15 downto 0)
    >>>>> I trust your answer Mike.


    Trust, but verify.
    Write a simple example and try it with your own tools.

    >>>>> What would INTEGER RANGE 0 TO 65535 do?
    >>>> As Andy said, it would give you a 16-bit unsigned integer.


    Yes. I would prefer NATURAL range 0 to 65535

    >>>> Significant drawbacks of vector types
    >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    >>>> * Can't directly assign numeric values to them


    Yes. My top annoyance as well.
    A work-around for this is to add the zero
    init constant to the right side expression:

    constant vec_zero_c : my_uns_vec_t := (others => '0');
    forty_seven_c := vec_zero_c + 47;

    >>>> Significant drawbacks of integer subtypes
    >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    >>>> * Anything >=32 bits is unreliable and/or broken


    Yes -- address math. This is the main reason why numeric_std is
    my default for numeric vectors of configurable width.

    >>> Wow, that's a pretty good summary of pro's and con's.
    >>> However, if a conversion between integer and std_logic_vector is
    >>> "messy", it should at least be noted that a slightly less messy
    >>> conversion is also required between signed/unsigned and
    >>> std_logic_vector.


    my_port <= std_logic_vector(my_uns_v); -- is this messy?

    > BTW, I thought of another disadvantage to integers: you cannot query
    > the range of an integer (or integer subtype) port/signal/variable. For
    > example, you can declare my_slv : std_logic_vector(my_port'range) to
    > make it the same length as the port; you cannot do that with an
    > integer port.


    Aligning variables to ports or subprogram args is one
    of my favorites. Easy to write and read.

    -- Mike Treseler
     
    Mike Treseler, Aug 1, 2007
    #10
  11. Andy Guest

    On Aug 1, 12:20 pm, Mike Treseler <> wrote:
    > Various correspondents wrote:
    > >>>>>>> i.e is there something analogues with short int?
    > >>>>>> numeric_std.unsigned(15 downto 0)
    > >>>>> I trust your answer Mike.

    >
    > Trust, but verify.
    > Write a simple example and try it with your own tools.
    >
    > >>>>> What would INTEGER RANGE 0 TO 65535 do?
    > >>>> As Andy said, it would give you a 16-bit unsigned integer.

    >
    > Yes. I would prefer NATURAL range 0 to 65535
    >
    > >>>> Significant drawbacks of vector types
    > >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > >>>> * Can't directly assign numeric values to them

    >
    > Yes. My top annoyance as well.
    > A work-around for this is to add the zero
    > init constant to the right side expression:
    >
    > constant vec_zero_c : my_uns_vec_t := (others => '0');
    > forty_seven_c := vec_zero_c + 47;
    >
    > >>>> Significant drawbacks of integer subtypes
    > >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > >>>> * Anything >=32 bits is unreliable and/or broken

    >
    > Yes -- address math. This is the main reason why numeric_std is
    > my default for numeric vectors of configurable width.
    >
    > >>> Wow, that's a pretty good summary of pro's and con's.
    > >>> However, if a conversion between integer and std_logic_vector is
    > >>> "messy", it should at least be noted that a slightly less messy
    > >>> conversion is also required between signed/unsigned and
    > >>> std_logic_vector.

    >
    > my_port <= std_logic_vector(my_uns_v); -- is this messy?
    >
    > > BTW, I thought of another disadvantage to integers: you cannot query
    > > the range of an integer (or integer subtype) port/signal/variable. For
    > > example, you can declare my_slv : std_logic_vector(my_port'range) to
    > > make it the same length as the port; you cannot do that with an
    > > integer port.

    >
    > Aligning variables to ports or subprogram args is one
    > of my favorites. Easy to write and read.
    >
    > -- Mike Treseler


    My point was that

    my_slv_port <= std_logic_vector(my_unsigned);

    is only slightly less messy than

    my_slv_port <= std_logic_vector(to_unsigned(my_natural,
    my_slv_port'length));

    Both are too verbose.

    Definitions of "messy" and "slightly less" are open to interpretation
    of course!

    My answer to the above is to make the port unsigned or natural in the
    first place. Only for top level ports on the device would I use SLV,
    unless it made sense to do so.

    And when I do, I use my favorite shortcut:

    subtype slv is std_logic_vector;

    That way I can write:

    my_slv_port <= slv(my_slv);

    or

    my_slv_port <= slv(to_unsigned(my_natural, my_slv_port));

    Andy
     
    Andy, Aug 1, 2007
    #11
    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. a
    Replies:
    18
    Views:
    490
    Charlie Gordon
    Sep 29, 2005
  2. David Geering

    longs, long longs, short short long ints . . . huh?!

    David Geering, Jan 8, 2007, in forum: C Programming
    Replies:
    15
    Views:
    563
    Keith Thompson
    Jan 11, 2007
  3. Replies:
    4
    Views:
    830
    Kaz Kylheku
    Oct 17, 2006
  4. Ioannis Vranos

    unsigned short, short literals

    Ioannis Vranos, Mar 4, 2008, in forum: C Programming
    Replies:
    5
    Views:
    682
    Eric Sosman
    Mar 5, 2008
  5. Andre
    Replies:
    5
    Views:
    542
    Keith Thompson
    Jul 17, 2012
Loading...

Share This Page