integer type output signal is synthesizable?

Discussion in 'VHDL' started by sonny, Sep 27, 2007.

  1. sonny

    sonny Guest

    hi,

    i got a small question about a synthesizable code.

    i map an output as integer from one component to an input, also
    integer type, in another component. would this code be synthesizable?
    there is a general discussion on integer type signals and variables,
    but no output and input...
    any kinda posts will be very helpful.... thx

    sonny
     
    sonny, Sep 27, 2007
    #1
    1. Advertising

  2. sonny

    KJ Guest

    On Sep 27, 10:51 am, sonny <> wrote:
    > hi,
    >
    > i got a small question about a synthesizable code.
    >
    > i map an output as integer from one component to an input, also
    > integer type, in another component. would this code be synthesizable?

    Yes, not a problem.

    > there is a general discussion on integer type signals and variables,
    > but no output and input...
    > any kinda posts will be very helpful.... thx
    >

    The one place where you might want to avoid anything other than
    std_logic/std_logic_vectors as input/output ports is at the very top
    level of the design. The reason for avoiding there is not because
    it's not synthesizable (it is) but the signal name will get munched up
    as it works its way through the tool chain because your design will
    have some output called 'My_integer_output' (as an example) but the
    output of the synthesizer will generally append on a suffix indicating
    the bit position within that output (i.e. '_0', '_1', etc.). Exactly
    how the signal gets renamed is tool dependent.

    KJ
     
    KJ, Sep 27, 2007
    #2
    1. Advertising

  3. On 27 Sep., 16:51, sonny <> wrote:
    > i map an output as integer from one component to an input, also
    > integer type, in another component. would this code be synthesizable?


    In general yes, but be aware, that integer has no clear defined width
    in VHDL. You should use integer range x to y instead of pure integer,
    as your synthesis result may vary between different tools and OS. And
    I would use integer range 0 to 2^n to have a good result.

    bye Thomas
     
    Thomas Stanka, Oct 4, 2007
    #3
  4. sonny

    KJ Guest

    "Thomas Stanka" <> wrote in message
    news:...
    > On 27 Sep., 16:51, sonny <> wrote:
    >> i map an output as integer from one component to an input, also
    >> integer type, in another component. would this code be synthesizable?

    >
    > In general yes, but be aware, that integer has no clear defined width
    > in VHDL.

    Integer ranges are quite well defined by the VHDL language, they are
    synthesized as 32 bit signed quantities.

    > You should use integer range x to y instead of pure integer,
    > as your synthesis result may vary between different tools and OS.

    No, you should use integer range x to y so that you don't synthesize a full
    32 bit integer when only a 4 bit one would do. It does not have to do with
    tools (unless the optomizer can somehow fathtom that it can get away with 4
    bits and still be LRM compliant) or OS

    > And
    > I would use integer range 0 to 2^n to have a good result.
    >

    I tend to use the app specifiec proper range, if something is in the range
    from 3 to 99 I would tend to use that range. The simulator catches usages
    that fall out of that range, synthesis implements the proper size integer,
    all is well.

    KJ
     
    KJ, Oct 4, 2007
    #4
  5. sonny

    Andy Guest

    On Oct 4, 6:19 am, "KJ" <> wrote:
    > "Thomas Stanka" <> wrote in message
    >
    > news:...> On 27 Sep., 16:51, sonny <> wrote:
    > >> i map an output as integer from one component to an input, also
    > >> integer type, in another component. would this code be synthesizable?

    >
    > > In general yes, but be aware, that integer has no clear defined width
    > > in VHDL.

    >
    > Integer ranges are quite well defined by the VHDL language, they are
    > synthesized as 32 bit signed quantities.
    >
    > > You should use integer range x to y instead of pure integer,
    > > as your synthesis result may vary between different tools and OS.

    >
    > No, you should use integer range x to y so that you don't synthesize a full
    > 32 bit integer when only a 4 bit one would do. It does not have to do with
    > tools (unless the optomizer can somehow fathtom that it can get away with 4
    > bits and still be LRM compliant) or OS
    >
    > > And
    > > I would use integer range 0 to 2^n to have a good result.

    >
    > I tend to use the app specifiec proper range, if something is in the range
    > from 3 to 99 I would tend to use that range. The simulator catches usages
    > that fall out of that range, synthesis implements the proper size integer,
    > all is well.
    >
    > KJ


    I'm with KJ on this one... I define the range of values expected/
    allowed, and let the synthesis tool create the minimum width to
    accommodate it. Note that offsets are not used by any tools I'm aware
    of, so "integer range 3 to 17" requires 5 bits, not 4. Nevertheless, I
    prefer that the simulator automatically enforce functional bounds
    checking on the object.

    I have had a case where a counter (integer range 0 to 5) decode was
    optimized to two bits for certain counts. But I'm not sure whether the
    synthesis tool used the range specification or a reachability analysis
    to come up with the optimization.

    Andy
     
    Andy, Oct 4, 2007
    #5
  6. On 4 Okt., 13:19, "KJ" <> wrote:
    > "Thomas Stanka" <> wrote in message
    >
    > news:...> On 27 Sep., 16:51, sonny <> wrote:
    > >> i map an output as integer from one component to an input, also
    > >> integer type, in another component. would this code be synthesizable?

    >
    > > In general yes, but be aware, that integer has no clear defined width
    > > in VHDL.

    >
    > Integer ranges are quite well defined by the VHDL language, they are
    > synthesized as 32 bit signed quantities.


    AFAIK is an VHDL integer defined as at least 32 bit but allowed to
    have more than 32 bit (eg 64bit on 64bit OS) (my knowledge may be out-
    of-date with the actual versions of VHDL 200x, but it should be valid
    for at least VHDL87.)
    A counter with full integer width may be 32 bit, but may also be 63
    bit or 64 bit depending on the internal integer representation.

    > > And
    > > I would use integer range 0 to 2^n to have a good result.

    >
    > I tend to use the app specifiec proper range, if something is in the range
    > from 3 to 99 I would tend to use that range. The simulator catches usages
    > that fall out of that range, synthesis implements the proper size integer,
    > all is well.


    This is good practice to catch out of range during simulation, but
    gives you a lot of work for formal verification for example.

    A subtype 0 to 2 results physical in two bit, but your code contains
    no information what to do, when the forbidden value "11"
    is reached due to any failure. This is especially fatal, when having
    IO-ports. The next designer using your code as IP may have no clue,
    that you expect some surrounding logic to ensure no forbidden input
    occures.

    bye Thomas
     
    Thomas Stanka, Oct 7, 2007
    #6
  7. sonny

    KJ Guest

    "Thomas Stanka" <> wrote in message
    news:...
    > On 4 Okt., 13:19, "KJ" <> wrote:
    >> "Thomas Stanka" <> wrote in message
    >>
    >> news:...> On 27 Sep.,
    >> 16:51, sonny <> wrote:
    >> >> i map an output as integer from one component to an input, also
    >> >> integer type, in another component. would this code be synthesizable?

    >>
    >> > In general yes, but be aware, that integer has no clear defined width
    >> > in VHDL.

    >>
    >> Integer ranges are quite well defined by the VHDL language, they are
    >> synthesized as 32 bit signed quantities.

    >
    > AFAIK is an VHDL integer defined as at least 32 bit but allowed to
    > have more than 32 bit (eg 64bit on 64bit OS) (my knowledge may be out-
    > of-date with the actual versions of VHDL 200x, but it should be valid
    > for at least VHDL87.)
    > A counter with full integer width may be 32 bit, but may also be 63
    > bit or 64 bit depending on the internal integer representation.
    >

    No. Integers are defined in the VHDL package standard as...
    type integer is range -2147483648 to 2147483647;

    >> > And
    >> > I would use integer range 0 to 2^n to have a good result.

    >>
    >> I tend to use the app specifiec proper range, if something is in the
    >> range
    >> from 3 to 99 I would tend to use that range. The simulator catches
    >> usages
    >> that fall out of that range, synthesis implements the proper size
    >> integer,
    >> all is well.

    >
    > This is good practice to catch out of range during simulation, but
    > gives you a lot of work for formal verification for example.

    Can you explain why the extra work for formal verification? I would think
    that what is being formally verified is conformance to the specification so
    if there is extra work it would imply that formal verification is verifying
    functionality above and beyond what the functional requirements for the
    design actually are. I haven't used such a tool, so if you do then you
    could likely enlighten me a bit on this because it's not clear why formal
    verification would have this extra work.

    >
    > A subtype 0 to 2 results physical in two bit, but your code contains
    > no information what to do, when the forbidden value "11"
    > is reached due to any failure.

    It should do whatever the functional requirements in the specification say
    that it should do. If there are no such requirements then the design is
    free to do whatever it wants. I might also point out that if the subtype
    was one hot coded then it could be implemented as a three bit code so there
    would be more than just one forbidden value.

    > This is especially fatal, when having
    > IO-ports.

    Which is why you can't always impose such a constraint on an input port.
    But again, it goes back to what the functional requirements in the spec say
    to do. If input pins are in some 'forbidden' combination, how should the
    part respond? I've yet to run across a spec from a supplier that says you
    can violate some requirement and still expect it to produce the correct
    output so why wouldn't the same apply to a programmable part? If such a
    condition exists and the part is supposed to flag it in some manner, then
    this behaviour would (should) be documented in the spec. In any case, using
    integers for top level ports is not a good idea anyway but for totally
    different reasons which I mentioned earlier in the thread. Blocks of IP
    that are intended for 'internal' blocks do not necessarily have those same
    requirements.

    > The next designer using your code as IP may have no clue,
    > that you expect some surrounding logic to ensure no forbidden input
    > occures.

    Actually they would be explicitly aware of this because the port would be
    specified with the required integer range (i.e. xyz: in natural range 0 to
    99). The point is not to somehow burden down the IP user with having to
    produce checking logic to insure that they are in the proper range, it is
    simply to specify what the operating range actually is.

    KJ
     
    KJ, Oct 7, 2007
    #7
  8. KJ wrote:

    > No. Integers are defined in the VHDL package standard as...
    > type integer is range -2147483648 to 2147483647;


    I think you wanted to say: type integer is range -2147483647 to 2147483647.
    The most negative value is missing.

    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
     
    Paul Uiterlinden, Oct 8, 2007
    #8
  9. sonny

    KJ Guest

    On Oct 8, 12:17 pm, Paul Uiterlinden <> wrote:
    > KJ wrote:
    > > No. Integers are defined in the VHDL package standard as...
    > > type integer is range -2147483648 to 2147483647;

    >
    > I think you wanted to say: type integer is range -2147483647 to 2147483647.
    > The most negative value is missing.
    >
    > --
    > Paul Uiterlindenwww.aimvalley.nl
    > e-mail addres: remove the not.


    Not according to the VHDL references that I use...or according to the
    Modelsim 6.2f\vhdl_src\std\standard.vhd file that I copy/pasted the
    information from.

    KJ
     
    KJ, Oct 8, 2007
    #9
  10. KJ wrote:

    > On Oct 8, 12:17 pm, Paul Uiterlinden <> wrote:
    >> KJ wrote:
    >> > No. Integers are defined in the VHDL package standard as...
    >> > type integer is range -2147483648 to 2147483647;

    >>
    >> I think you wanted to say: type integer is range -2147483647 to
    >> 2147483647. The most negative value is missing.

    >
    > Not according to the VHDL references that I use...or according to the
    > Modelsim 6.2f\vhdl_src\std\standard.vhd file that I copy/pasted the
    > information from.


    Ah, I see. Sorry for truing to put words into your mouth. ;-)

    If your VHDL references really say that the minimum required range on type
    integer is -2147483648 to 2147483647, then those references are wrong.
    According to the 1993 LRM the minimum required range is -2147483647 to
    2147483647.

    As for ModelSim: a simulator may support a wider range. The trouble with
    that however is portability. If your code makes use of the wider range, it
    could fail on a different simulator. Therefore I never convert a vector
    larger than 31 bits to an integer. If I would do that, this one magical
    value would lurk in the dark, waiting to pop up at an inconvenient moment.

    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
     
    Paul Uiterlinden, Oct 8, 2007
    #10
  11. sonny

    KJ Guest

    On Oct 8, 4:24 pm, Paul Uiterlinden <> wrote:
    > KJ wrote:
    > > On Oct 8, 12:17 pm, Paul Uiterlinden <> wrote:
    > >> KJ wrote:
    > >> > No. Integers are defined in the VHDL package standard as...
    > >> > type integer is range -2147483648 to 2147483647;

    >
    > >> I think you wanted to say: type integer is range -2147483647 to
    > >> 2147483647. The most negative value is missing.

    >
    > > Not according to the VHDL references that I use...or according to the
    > > Modelsim 6.2f\vhdl_src\std\standard.vhd file that I copy/pasted the
    > > information from.

    >
    > Ah, I see. Sorry for truing to put words into your mouth. ;-)
    >
    > If your VHDL references really say that the minimum required range on type
    > integer is -2147483648 to 2147483647, then those references are wrong.
    > According to the 1993 LRM the minimum required range is -2147483647 to
    > 2147483647.
    >

    Wow! I realize it's kind of a subtle point but the first two
    references I grabbed both had ...648 and both knew about and discussed
    changes that occurred in VHDL-93 so I guess both missed that also.

    "VHDL for Logic Synthesis", Second Edition, Andrew Rushton
    "Digital Design and Modeling with VHDL and Synthesis", K.C. Chang

    I took a look just now at Synplify 8.9 and they have ...647 so it
    looks like they got it right. I guess I should go check some of my
    others as well then, see what they have to say for themselves.

    > As for ModelSim: a simulator may support a wider range.

    Ummm....daring to ask, does the LRM actually say that? If so, then
    why in the world would that be? I realize that the processors that
    run the simulator may have different interpretations of what an
    'integer' is but why would the VHDL language definition allow
    simulators to have different interpretations of a basic part of the
    language that has been defined (and apparently redefined) from the
    begining?

    > The trouble with
    > that however is portability. If your code makes use of the wider range, it
    > could fail on a different simulator. Therefore I never convert a vector
    > larger than 31 bits to an integer. If I would do that, this one magical
    > value would lurk in the dark, waiting to pop up at an inconvenient moment.
    >

    I don't think I've ever really needed -2147483648, -2147483647 is
    probably close enough.

    Actually, I'm inclined to submit this as a trouble report to the good
    folks at Modelsim. To be fair though, the file that has this also has
    the following comment at the top...

    This is Package STANDARD as defined in the VHDL 1992 Language
    Reference Manual

    Unless I run across some other file for the 93 language, this would
    imply that they do not quite fully support -93 as they say (unless the
    LRM does give them the out that you alluded to earlier).

    Ah well, maybe not worth the trouble....but thanks for the
    clarification, learn something new every day.

    KJ
     
    KJ, Oct 8, 2007
    #11
  12. On 7 Okt., 23:49, "KJ" <> wrote:
    > >> > In general yes, but be aware, that integer has no clear defined width
    > >> > in VHDL.

    >
    > >> Integer ranges are quite well defined by the VHDL language, they are
    > >> synthesized as 32 bit signed quantities.

    >
    > > AFAIK is an VHDL integer defined as at least 32 bit but allowed to
    > > have more than 32 bit (eg 64bit on 64bit OS) (my knowledge may be out-
    > > of-date with the actual versions of VHDL 200x, but it should be valid
    > > for at least VHDL87.)
    > > A counter with full integer width may be 32 bit, but may also be 63
    > > bit or 64 bit depending on the internal integer representation.

    >
    > No. Integers are defined in the VHDL package standard as...
    > type integer is range -2147483648 to 2147483647;


    The package standard in modelsim is not the golden reference.
    Integer is defined to have _at_least_ this width in the VHDL-LRM.
    Each synthesis tool is allowed to use any other representation of
    integer, as far as integer covers at least 32 bit. It would be no bug,
    if your synthesis tool uses a port width of 64 or 128 bit when you
    defined the IO as integer without range.

    bye Thomas
     
    Thomas Stanka, Oct 9, 2007
    #12
  13. KJ <> writes:
    >> As for ModelSim: a simulator may support a wider range.

    > Ummm....daring to ask, does the LRM actually say that?


    Yes.

    "The range of INTEGER is implementation dependent, but it is
    guaranteed to include the range ~2147483647 to +2147483647"

    > Actually, I'm inclined to submit this as a trouble report to the good
    > folks at Modelsim.


    Why? It's a legal range and so much easier to be used internally as
    `int32_t'.

    Regards
    Marcus

    --
    note that "property" can also be used as syntaxtic sugar to reference
    a property, breaking the clean design of verilog; [...]

    (seen on http://www.veripool.com/verilog-mode_news.html)
     
    Marcus Harnisch, Oct 9, 2007
    #13
  14. sonny

    KJ Guest

    On Oct 9, 7:38 am, Marcus Harnisch <> wrote:
    > KJ <> writes:
    > >> As for ModelSim: a simulator may support a wider range.

    > > Ummm....daring to ask, does the LRM actually say that?

    >
    > Yes.
    >
    > "The range of INTEGER is implementation dependent, but it is
    > guaranteed to include the range ~2147483647 to +2147483647"
    >
    > > Actually, I'm inclined to submit this as a trouble report to the good
    > > folks at Modelsim.

    >
    > Why? It's a legal range and so much easier to be used internally as
    > `int32_t'.
    >

    Which is why I also said...
    (unless the LRM does give them the out that you alluded to earlier).

    KJ
     
    KJ, Oct 9, 2007
    #14
  15. KJ wrote:

    >> If your VHDL references really say that the minimum required range on
    >> type integer is -2147483648 to 2147483647, then those references are
    >> wrong. According to the 1993 LRM the minimum required range is
    >> -2147483647 to 2147483647.
    >>

    > Wow! I realize it's kind of a subtle point but the first two
    > references I grabbed both had ...648 and both knew about and discussed
    > changes that occurred in VHDL-93 so I guess both missed that also.


    This has not changed from 87 to 93.

    > "VHDL for Logic Synthesis", Second Edition, Andrew Rushton
    > "Digital Design and Modeling with VHDL and Synthesis", K.C. Chang
    >
    > I took a look just now at Synplify 8.9 and they have ...647 so it
    > looks like they got it right. I guess I should go check some of my
    > others as well then, see what they have to say for themselves.
    >
    >> As for ModelSim: a simulator may support a wider range.

    > Ummm....daring to ask, does the LRM actually say that?


    Yes, section 3.1.2.1 of the both the 87 an 93 LRM (and I suppose 2002):

    "The only predefined integer type is type INTEGER. The range of INTEGER is
    implementation dependent, but is guaranteed to include the
    range -2147483647 to 2147483648. It is defined with an ascending range.
    Note: The range of INTEGER in a particular implementation may be determined
    from the 'LOW and 'HIGH attributes".

    > If so, then why in the world would that be?


    I suppose to leave a free path for future extension. But I'd rather see a
    new type and/or subtype for that.

    What intrigues me is why this one magical number is left out. Is it because
    it is the only number besides zero that shows the same bits when taking its
    two's complement? I'm not sure.

    > I realize that the processors that
    > run the simulator may have different interpretations of what an
    > 'integer' is but why would the VHDL language definition allow
    > simulators to have different interpretations of a basic part of the
    > language that has been defined (and apparently redefined) from the
    > begining?


    Nothing has been redefined. It has always been like that.

    >> The trouble with
    >> that however is portability. If your code makes use of the wider range,
    >> it could fail on a different simulator. Therefore I never convert a
    >> vector larger than 31 bits to an integer. If I would do that, this one
    >> magical value would lurk in the dark, waiting to pop up at an
    >> inconvenient moment.
    >>

    > I don't think I've ever really needed -2147483648, -2147483647 is
    > probably close enough.


    Close enough is not good enough. Converting vector X"8000_0000" to an
    integer and back can give more than a difference of one, depending on the
    simulator. The best case is a fatal error. If you're really unlucky it can
    be anything without any error or warning.

    > Actually, I'm inclined to submit this as a trouble report to the good
    > folks at Modelsim.


    No, even if they had chosen to use signed 42 bits it would still comply with
    the standard.

    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
     
    Paul Uiterlinden, Oct 9, 2007
    #15
  16. sonny

    KJ Guest

    "Paul Uiterlinden" <> wrote in message
    news:470beedd$0$235

    Earlier in the thread in a post from you....
    >>> . According to the 1993 LRM the minimum required range is
    >>> -2147483647 to 2147483647.


    Latest posting...
    >
    > Yes, section 3.1.2.1 of the both the 87 an 93 LRM (and I suppose 2002):
    >
    > "The only predefined integer type is type INTEGER. The range of INTEGER is
    > implementation dependent, but is guaranteed to include the
    > range -2147483647 to 2147483648. It is defined with an ascending range.


    So I guess even among those who quote the LRM, those boundary values are a
    pain ;)

    KJ
     
    KJ, Oct 10, 2007
    #16
  17. KJ wrote:

    > "Paul Uiterlinden" <> wrote in message
    > news:470beedd$0$235
    >
    > Earlier in the thread in a post from you....
    >>>> . According to the 1993 LRM the minimum required range is
    >>>> -2147483647 to 2147483647.

    >
    > Latest posting...
    >>
    >> Yes, section 3.1.2.1 of the both the 87 an 93 LRM (and I suppose 2002):
    >>
    >> "The only predefined integer type is type INTEGER. The range of INTEGER
    >> is implementation dependent, but is guaranteed to include the
    >> range -2147483647 to 2147483648. It is defined with an ascending range.

    >
    > So I guess even among those who quote the LRM, those boundary values are a
    > pain ;)


    Apparently my brain fell apart into bits there for a moment. Thirty two bits
    to be exact.

    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
     
    Paul Uiterlinden, Oct 10, 2007
    #17
    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. Michael Pronath
    Replies:
    1
    Views:
    1,238
    Diez B. Roggisch
    Jan 3, 2005
  2. Jack Orenstein

    threading.Thread vs. signal.signal

    Jack Orenstein, Sep 18, 2005, in forum: Python
    Replies:
    0
    Views:
    500
    Jack Orenstein
    Sep 18, 2005
  3. Weng Tianxiang
    Replies:
    2
    Views:
    689
    Jonathan Bromley
    Jan 30, 2007
  4. Nicolas Moreau
    Replies:
    9
    Views:
    3,358
  5. dibacco73
    Replies:
    1
    Views:
    697
    joris
    Feb 12, 2009
Loading...

Share This Page