boolean operations on "integer" in VHDL'93

Discussion in 'VHDL' started by whygee, Nov 4, 2010.

  1. whygee

    whygee Guest

    Hello,

    I really miss the "or", "and", "xor", "not", "shr", "shl" etc.
    operators in the "integer" type. To my knowledge, they are available
    only for the types like std_(u)logic(_vector) but they are... slow.
    I would like to do some quick behavioural stuff and
    I'm ready to code some extensions to my favorite simulator
    (GHDL) but I wonder if anyone knows an existing solution.

    Any hint ? Did I miss something ?

    yg
    --
    http://ygdes.com / http://yasep.org
     
    whygee, Nov 4, 2010
    #1
    1. Advertising

  2. Le 04/11/2010 12:28, whygee a écrit :
    > Hello,
    >
    > I really miss the "or", "and", "xor", "not", "shr", "shl" etc.
    > operators in the "integer" type. To my knowledge, they are available
    > only for the types like std_(u)logic(_vector) but they are... slow.
    > I would like to do some quick behavioural stuff and
    > I'm ready to code some extensions to my favorite simulator
    > (GHDL) but I wonder if anyone knows an existing solution.
    >
    > Any hint ? Did I miss something ?


    That's strong typing for you...

    Nicolas
     
    Nicolas Matringe, Nov 4, 2010
    #2
    1. Advertising

  3. whygee

    whygee Guest

    Hi !

    Brian Drummond wrote:
    > On Thu, 04 Nov 2010 12:28:31 +0100, whygee <> wrote:
    >> Any hint ? Did I miss something ?

    > bit_vector should be less heavyweight than std_logic_vector.

    sure but i want to use integers :-/

    > - Brian


    Nicolas Matringe wrote :
    > That's strong typing for you...

    it's not a problem of typing, i can create new functions,
    however I see nowhere an explanation of these missing operations.
    why do AND/OR/XOR work on bit(_vector) and std_(u)logic(vector)
    and not on integer, as in any other language ?

    > Nicolas

    yg
    --
    http://ygdes.com / http://yasep.org
     
    whygee, Nov 5, 2010
    #3
  4. whygee

    backhus Guest

    On 5 Nov., 05:30, whygee <> wrote:
    > Hi !
    >
    > Brian Drummond wrote:
    > > On Thu, 04 Nov 2010 12:28:31 +0100, whygee <> wrote:
    > >> Any hint ? Did I miss something ?

    > > bit_vector should be less heavyweight than std_logic_vector.

    >
    > sure but i want to use integers :-/
    >
    >  > - Brian
    >
    > Nicolas Matringe wrote :
    >  > That's strong typing for you...
    > it's not a problem of typing, i can create new functions,
    > however I see nowhere an explanation of these missing operations.
    > why do AND/OR/XOR work on bit(_vector) and std_(u)logic(vector)
    > and not on integer, as in any other language ?
    >
    >  > Nicolas
    > yg
    > --http://ygdes.com/http://yasep.org


    Hi,
    maybe it's because integers were not intended to be used for your
    logic data.
    They are made for array indexing and loop counting stuff, where the
    need for logic functions is neglectible.

    If you want to do convenient algorithmic stuff with VHDL use
    numeric_std types signed and unsigned.

    While the std_logic types need more computing time in your simulator,
    the advantage is that they are not limited to 32 bit max. width.
    You may not need this in your current project, but maybe somewhen.

    Have a nice simulation
    Eilert
     
    backhus, Nov 5, 2010
    #4
  5. whygee

    Tricky Guest

    On Nov 4, 11:28 am, whygee <> wrote:
    > Hello,
    >
    > I really miss the "or", "and", "xor", "not", "shr", "shl" etc.
    > operators in the "integer" type. To my knowledge, they are available
    > only for the types like std_(u)logic(_vector) but they are... slow.
    > I would like to do some quick behavioural stuff and
    > I'm ready to code some extensions to my favorite simulator
    > (GHDL) but I wonder if anyone knows an existing solution.
    >
    > Any hint ? Did I miss something ?
    >
    > yg
    > --http://ygdes.com/http://yasep.org


    Use signed/unsigned instead? you can do arithmatic and boolean with
    them.
     
    Tricky, Nov 5, 2010
    #5
  6. whygee

    Jan Decaluwe Guest

    Brian Drummond wrote:

    > Not "any" other language.
    >
    > Mainly C and its followers, which tend to trade a superficial convenience for a
    > thousand subtle ways to screw yourself.
    >
    > These operations are not "missing" in VHDL's integer types; they were never part
    > of Integer at any time in the history of mathematics, and there is no rational
    > reason for them to be now.
    >
    > They basically crept into C's "int" via some late 1960's assembly language, and
    > we have been paying the price in software "quality" ever since.
    >
    > If you need to "AND" two quantities, you can be pretty close to certain that
    > they are, fundamentally, not integers. Instructions, perhaps. Sets of bits,
    > maybe. Control signals, possibly.
    >
    > Oh and while I'm still coffee-deprived, adding two positive integers will NEVER
    > EVER result in a negative integer. Integers don't, and can't, overflow.
    >
    > From which we can see that C doesn't actually have ANY integer data types at all
    > - merely a bit-vector type, misleadingly labelled "int", on which they allow
    > instructions that occasionally resemble addition, etc. (Pedantically, modulo-n
    > addition).
    >
    > Oh, and "unsigned char", as if there was ever such a thing as a signed
    > character.


    All true, but I think it is also possible to do it right and that
    the result is very useful, especially for hardware designers.

    I think a language like Python does it right. Integers are true integers,
    but through the boolean operators you have access to the underlying
    2's complement representation if desired.

    What I do in MyHDL with the intbv type, is to add an indexing and slicing
    interface to such integers. The result is indeed a "dual mode" type. But
    for arithmetic, it doesn't have any of the confusion of signed/unsigned.
    I believe this is exactly what hardware designers need in practice.

    Jan

    --
    Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com
     
    Jan Decaluwe, Nov 5, 2010
    #6
  7. whygee

    rickman Guest

    On Nov 5, 5:20 am, Jan Decaluwe <> wrote:
    > Brian Drummond wrote:
    > > Not "any" other language.

    >
    > > Mainly C and its followers, which tend to trade a superficial convenience for a
    > > thousand subtle ways to screw yourself.

    >
    > > These operations are not "missing" in VHDL's integer types; they were never part
    > > of Integer at any time in the history of mathematics, and there is no rational
    > > reason for them to be now.

    >
    > > They basically crept into C's "int" via some late 1960's assembly language, and
    > > we have been paying the price in software "quality" ever since.

    >
    > > If you need to "AND" two quantities, you can be pretty close to certain that
    > > they are, fundamentally, not integers. Instructions, perhaps. Sets of bits,
    > > maybe. Control signals, possibly.

    >
    > > Oh and while I'm still  coffee-deprived, adding two positive integers will NEVER
    > > EVER result in a negative integer. Integers don't, and can't, overflow.

    >
    > > From which we can see that C doesn't actually have ANY integer data types at all
    > > - merely a bit-vector type, misleadingly labelled "int", on which they allow
    > > instructions that occasionally resemble addition, etc. (Pedantically, modulo-n
    > > addition).

    >
    > > Oh, and "unsigned char", as if there was ever such a thing as a signed
    > > character.

    >
    > All true, but I think it is also possible to do it right and that
    > the result is very useful, especially for hardware designers.
    >
    > I think a language like Python does it right. Integers are true integers,
    > but through the boolean operators you have access to the underlying
    > 2's complement representation if desired.


    But that is the problem. Who says an integer is implemented as a 2's
    complement binary signal array?

    > What I do in MyHDL with the intbv type, is to add an indexing and slicing
    > interface to such integers. The result is indeed a "dual mode" type. But
    > for arithmetic, it doesn't have any of the confusion of signed/unsigned.
    > I believe this is exactly what hardware designers need in practice.


    So MyHDL assumes a specific implementation of integers in the
    hardware?

    If the OP wants to treat integers as an array of a binary data type,
    then he needs to write the functions to do that. He will either need
    to convert the integers to an array of binary values and perform the
    logic operation on those, or he can use looping constructs to isolate
    the individual bits of the integer and operate on those.

    The problem is not that it can't be done, the OP simply doesn't know
    how to write a function to do this. He is thinking at a very simple
    level expecting there to be logic operators on integers for him to
    use. He needs to consider how logic operators could be implemented on
    integers.

    Rick
     
    rickman, Nov 5, 2010
    #7
  8. whygee

    Jan Decaluwe Guest

    rickman wrote:
    > On Nov 5, 5:20 am, Jan Decaluwe <> wrote:


    >>
    >> I think a language like Python does it right. Integers are true integers,
    >> but through the boolean operators you have access to the underlying
    >> 2's complement representation if desired.

    >
    > But that is the problem. Who says an integer is implemented as a 2's
    > complement binary signal array?


    The Python Language LRM of course. It's not an axioma. Other definitions
    and languages are perfectly feasible, although less practical probably.

    >> What I do in MyHDL with the intbv type, is to add an indexing and slicing
    >> interface to such integers. The result is indeed a "dual mode" type. But
    >> for arithmetic, it doesn't have any of the confusion of signed/unsigned.
    >> I believe this is exactly what hardware designers need in practice.

    >
    > So MyHDL assumes a specific implementation of integers in the
    > hardware?


    The intbv type is an integer-like type with a defined bit-vector
    representation. Much like Verilog's signed and unsigned regs, with
    the big difference that integer arithmetic works as it should.
    At the same time, it's more "abstract" than VHDL's integer - no
    arbitrary 32 bit limit.

    Intbv's can be used as integers without ever referring to their
    bit vector representation. They can also be used as bit vectors
    without ever referring to their integer interpretation, for example
    to represent integers in different ways in hardware. However, it
    is equally possible to mix the 2 interpretations as needed. Let's
    be honest, that happens all the time in practical hardware design.

    I have a lot of sympathy for purity, but I find your call to it
    a litte surprizing. I thought you were in the process of moving
    from VHDL to Verilog for practical reasons :) ?

    Jan

    --
    Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com
     
    Jan Decaluwe, Nov 5, 2010
    #8
  9. whygee

    whygee Guest

    Hi everybody !
    It's nice to see some activity here :)

    To Tricky and Eilert :
    Yes of course I know numeric_std (signed and unsigned) enough
    to see what it is good for and to know it does not address my need.

    Currently I'm not looking at synthesisable code
    but behavioural description. I want to avoid SystemC
    and similar oddities, why would I need them when I have GHDL ? :)
    And when the behaviour is right, i translate to std_ulogic.

    rickman wrote:
    > On Nov 5, 5:20 am, Jan Decaluwe <> wrote:
    >> Brian Drummond wrote:
    >>> Not "any" other language.
    >>> Mainly C and its followers, which tend to trade a superficial convenience for a
    >>> thousand subtle ways to screw yourself.

    CRAY screwed with floating point, but despite the high costs,
    it sold well. Hint : it was FAST. Yet I know the reluctantly accepted IEEE758,
    the same way they accepted 2-s complement after the CDC line which was 1s complement.

    I don't want to screw with arithmetics or standards.
    I just see that I spend too much time coding and simulating individual
    bits when the simulator's CPU can do a much simpler and faster work.

    I'll sort all the initialisation and other usual issues of my models later
    (during the transition to std_ulogic)
    but i don't think there will be much to care about because i use to code
    defensivly and forward-looking.

    >>> These operations are not "missing" in VHDL's integer types; they were never part
    >>> of Integer at any time in the history of mathematics, and there is no rational
    >>> reason for them to be now.

    I'm not doing mathematics, i'm doing digital electronics and I look at what
    does the job fastest :) Don't worry : std_ulogic is not going to be thrown away,
    or else, how will i synthesise my code ?

    >>> They basically crept into C's "int" via some late 1960's assembly language, and
    >>> we have been paying the price in software "quality" ever since.
    >>> If you need to "AND" two quantities, you can be pretty close to certain that
    >>> they are, fundamentally, not integers. Instructions, perhaps. Sets of bits,
    >>> maybe. Control signals, possibly.

    yes, so what ?
    data is data.

    >>> Oh and while I'm still coffee-deprived, adding two positive integers will NEVER
    >>> EVER result in a negative integer. Integers don't, and can't, overflow.
    >>> From which we can see that C doesn't actually have ANY integer data types at all
    >>> - merely a bit-vector type, misleadingly labelled "int", on which they allow
    >>> instructions that occasionally resemble addition, etc. (Pedantically, modulo-n
    >>> addition).

    i agree.

    On the other side, how many times did you see in VHDL "x / 2**y "
    that makes a stupid bit shift using a divide (slow) and an exponential ? (super slow) ?

    >>> Oh, and "unsigned char", as if there was ever such a thing as a signed
    >>> character.

    haha :)

    >> All true, but I think it is also possible to do it right and that
    >> the result is very useful, especially for hardware designers.

    more precisely : designers who know HW and SW well.
    I often hear the argument : "don't do X because it is potentially dangerous".
    Fine, I know the dangers and I take appropriate precautions. C integers are a bitch
    but I know them for a while now so I can code defensively and efficiently.

    >> I think a language like Python does it right. Integers are true integers,
    >> but through the boolean operators you have access to the underlying
    >> 2's complement representation if desired.

    >
    > But that is the problem. Who says an integer is implemented as a 2's
    > complement binary signal array?


    it's a convenient compromise, it is adopted by ... all the new computer
    architectures since the 1980's that i know. Now if you prefer 1's complement,
    it's not my problem :)

    >> What I do in MyHDL with the intbv type, is to add an indexing and slicing
    >> interface to such integers. The result is indeed a "dual mode" type. But
    >> for arithmetic, it doesn't have any of the confusion of signed/unsigned.
    >> I believe this is exactly what hardware designers need in practice.

    >
    > So MyHDL assumes a specific implementation of integers in the
    > hardware?
    >
    > If the OP wants to treat integers as an array of a binary data type,
    > then he needs to write the functions to do that.
    > He will either need
    > to convert the integers to an array of binary values and perform the
    > logic operation on those, or he can use looping constructs to isolate
    > the individual bits of the integer and operate on those.

    There are 3 ways :
    - as you wrote : plain slow (use of std_ulogic is faster)
    - modify the compiler : that's a long-term goal
    - VHPIDIRECT : what i'll do first :)
    it only works with GHDL (maybe Aldec) but it's easy and fast to write
    and it's a first step to defining the behaviour of the boolean extension
    before the compiler is modified.

    > The problem is not that it can't be done, the OP simply doesn't know
    > how to write a function to do this.

    Rick, I thought you knew me better :-/

    > He is thinking at a very simple
    > level expecting there to be logic operators on integers for him to
    > use. He needs to consider how logic operators could be implemented on
    > integers.

    give me 48h (well 2h are enough) and i'll show you a few tricks :)
    Did I say that I have added a graphic framebuffer interface to GHDL,
    or I wrote code that reads the computer's environment variables ?
    OK it's only for GHDL but it works great and once you understand
    the guts, it's easy :)

    Talk to you all soon,

    > Rick

    yg
    --
    http://ygdes.com / http://yasep.org
     
    whygee, Nov 5, 2010
    #9
  10. whygee

    rickman Guest

    On Nov 5, 10:09 am, Jan Decaluwe <> wrote:
    > rickman wrote:
    > > On Nov 5, 5:20 am, Jan Decaluwe <> wrote:

    >
    > >> I think a language like Python does it right. Integers are true integers,
    > >> but through the boolean operators you have access to the underlying
    > >> 2's complement representation if desired.

    >
    > > But that is the problem.  Who says an integer is implemented as a 2's
    > > complement binary signal array?

    >
    > The Python Language LRM of course. It's not an axioma. Other definitions
    > and languages are perfectly feasible, although less practical probably.


    That's great, but not useful for hardware design is it?


    > >> What I do in MyHDL with the intbv type, is to add an indexing and slicing
    > >> interface to such integers. The result is indeed a "dual mode" type. But
    > >> for arithmetic, it doesn't have any of the confusion of signed/unsigned.
    > >> I believe this is exactly what hardware designers need in practice.

    >
    > > So MyHDL assumes a specific implementation of integers in the
    > > hardware?

    >
    > The intbv type is an integer-like type with a defined bit-vector
    > representation. Much like Verilog's signed and unsigned regs, with
    > the big difference that integer arithmetic works as it should.
    > At the same time, it's more "abstract" than VHDL's integer - no
    > arbitrary 32 bit limit.
    >
    > Intbv's can be used as integers without ever referring to their
    > bit vector representation. They can also be used as bit vectors
    > without ever referring to their integer interpretation, for example
    > to represent integers in different ways in hardware. However, it
    > is equally possible to mix the 2 interpretations as needed. Let's
    > be honest, that happens all the time in practical hardware design.
    >
    > I have a lot of sympathy for purity, but I find your call to it
    > a litte surprizing. I thought you were in the process of moving
    > from VHDL to Verilog for practical reasons :) ?


    I won't say the intent was "for practical reasons". It is more that I
    want to find out for myself what is good and bad about Verilog and
    possibly be more compatible with customers. I don't have a need for
    "purity" and I don't think I said that. HDLs are designed to be
    implementation independent unless you want to specify an
    implementation. Integers in VHDL are not intended to specify
    implementation, while signed and unsigned are. Is being
    implementation independent the same as being "pure"?

    Besides, I explained how integers can be treated as bit vectors with
    two choices. You just need to define your own functions for it.

    Rick
     
    rickman, Nov 5, 2010
    #10
  11. whygee

    Tricky Guest

    On Nov 5, 2:09 pm, Jan Decaluwe <> wrote:
    > rickman wrote:
    > > On Nov 5, 5:20 am, Jan Decaluwe <> wrote:

    >
    > >> I think a language like Python does it right. Integers are true integers,
    > >> but through the boolean operators you have access to the underlying
    > >> 2's complement representation if desired.

    >
    > > But that is the problem.  Who says an integer is implemented as a 2's
    > > complement binary signal array?

    >
    > The Python Language LRM of course. It's not an axioma. Other definitions
    > and languages are perfectly feasible, although less practical probably.
    >
    > >> What I do in MyHDL with the intbv type, is to add an indexing and slicing
    > >> interface to such integers. The result is indeed a "dual mode" type. But
    > >> for arithmetic, it doesn't have any of the confusion of signed/unsigned.
    > >> I believe this is exactly what hardware designers need in practice.

    >
    > > So MyHDL assumes a specific implementation of integers in the
    > > hardware?

    >
    > The intbv type is an integer-like type with a defined bit-vector
    > representation. Much like Verilog's signed and unsigned regs, with
    > the big difference that integer arithmetic works as it should.
    > At the same time, it's more "abstract" than VHDL's integer - no
    > arbitrary 32 bit limit.
    >
    > Intbv's can be used as integers without ever referring to their
    > bit vector representation. They can also be used as bit vectors
    > without ever referring to their integer interpretation, for example
    > to represent integers in different ways in hardware. However, it
    > is equally possible to mix the 2 interpretations as needed. Let's
    > be honest, that happens all the time in practical hardware design.
    >
    > I have a lot of sympathy for purity, but I find your call to it
    > a litte surprizing. I thought you were in the process of moving
    > from VHDL to Verilog for practical reasons :) ?
    >
    > Jan
    >
    > --
    > Jan Decaluwe - Resources bvba -http://www.jandecaluwe.com
    >     Python as a HDL:http://www.myhdl.org
    >     VHDL development, the modern way:http://www.sigasi.com
    >     Analog design automation:http://www.mephisto-da.com
    >     World-class digital design:http://www.easics.com


    Can you explain to me why you should use intbv over signed/unsigned?
     
    Tricky, Nov 5, 2010
    #11
  12. whygee

    Jan Decaluwe Guest

    Jan Decaluwe, Nov 5, 2010
    #12
  13. whygee

    Jan Decaluwe Guest

    rickman wrote:
    > On Nov 5, 10:09 am, Jan Decaluwe <> wrote:
    >> rickman wrote:
    >>> On Nov 5, 5:20 am, Jan Decaluwe <> wrote:
    >>>> I think a language like Python does it right. Integers are true integers,
    >>>> but through the boolean operators you have access to the underlying
    >>>> 2's complement representation if desired.
    >>> But that is the problem. Who says an integer is implemented as a 2's
    >>> complement binary signal array?

    >> The Python Language LRM of course. It's not an axioma. Other definitions
    >> and languages are perfectly feasible, although less practical probably.

    >
    > That's great, but not useful for hardware design is it?


    I don't see what you are referring to here. It can't be Python/MyHDL's
    actual choice, because that is the same as VHDL/Verilog for signed, and
    probably any VHDL synthesis tool for integer.

    >>>> What I do in MyHDL with the intbv type, is to add an indexing and slicing
    >>>> interface to such integers. The result is indeed a "dual mode" type. But
    >>>> for arithmetic, it doesn't have any of the confusion of signed/unsigned.
    >>>> I believe this is exactly what hardware designers need in practice.
    >>> So MyHDL assumes a specific implementation of integers in the
    >>> hardware?

    >> The intbv type is an integer-like type with a defined bit-vector
    >> representation. Much like Verilog's signed and unsigned regs, with
    >> the big difference that integer arithmetic works as it should.
    >> At the same time, it's more "abstract" than VHDL's integer - no
    >> arbitrary 32 bit limit.
    >>
    >> Intbv's can be used as integers without ever referring to their
    >> bit vector representation. They can also be used as bit vectors
    >> without ever referring to their integer interpretation, for example
    >> to represent integers in different ways in hardware. However, it
    >> is equally possible to mix the 2 interpretations as needed. Let's
    >> be honest, that happens all the time in practical hardware design.
    >>
    >> I have a lot of sympathy for purity, but I find your call to it
    >> a litte surprizing. I thought you were in the process of moving
    >> from VHDL to Verilog for practical reasons :) ?

    >
    > I won't say the intent was "for practical reasons". It is more that I
    > want to find out for myself what is good and bad about Verilog and
    > possibly be more compatible with customers. I don't have a need for
    > "purity" and I don't think I said that.


    Agreed, you complained about the consequences of VHDL's strong
    typing system. But that's what I intended to refer to also.

    > HDLs are designed to be
    > implementation independent unless you want to specify an
    > implementation. Integers in VHDL are not intended to specify
    > implementation, while signed and unsigned are. Is being
    > implementation independent the same as being "pure"?


    That's what I mean, yes: strong typing and abstract types without
    an implied representation, such as VHDL's boolean, enum and
    integer. I'm personally all for it,

    > Besides, I explained how integers can be treated as bit vectors with
    > two choices. You just need to define your own functions for it.


    Note that would have to make choice how to represent integers
    in those function. I wonder what that choice would be :)

    Jan

    --
    Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com
     
    Jan Decaluwe, Nov 5, 2010
    #13
  14. whygee

    Jan Decaluwe Guest

    rickman wrote:
    > On Nov 5, 10:09 am, Jan Decaluwe <> wrote:
    >> rickman wrote:
    >>> On Nov 5, 5:20 am, Jan Decaluwe <> wrote:
    >>>> I think a language like Python does it right. Integers are true integers,
    >>>> but through the boolean operators you have access to the underlying
    >>>> 2's complement representation if desired.
    >>> But that is the problem. Who says an integer is implemented as a 2's
    >>> complement binary signal array?

    >> The Python Language LRM of course. It's not an axioma. Other definitions
    >> and languages are perfectly feasible, although less practical probably.

    >
    > That's great, but not useful for hardware design is it?


    I don't see what you are referring to here. It can't be Python/MyHDL's
    actual choice, because that is the same as VHDL/Verilog for signed, and
    probably any VHDL synthesis tool for integer.

    >>>> What I do in MyHDL with the intbv type, is to add an indexing and slicing
    >>>> interface to such integers. The result is indeed a "dual mode" type. But
    >>>> for arithmetic, it doesn't have any of the confusion of signed/unsigned.
    >>>> I believe this is exactly what hardware designers need in practice.
    >>> So MyHDL assumes a specific implementation of integers in the
    >>> hardware?

    >> The intbv type is an integer-like type with a defined bit-vector
    >> representation. Much like Verilog's signed and unsigned regs, with
    >> the big difference that integer arithmetic works as it should.
    >> At the same time, it's more "abstract" than VHDL's integer - no
    >> arbitrary 32 bit limit.
    >>
    >> Intbv's can be used as integers without ever referring to their
    >> bit vector representation. They can also be used as bit vectors
    >> without ever referring to their integer interpretation, for example
    >> to represent integers in different ways in hardware. However, it
    >> is equally possible to mix the 2 interpretations as needed. Let's
    >> be honest, that happens all the time in practical hardware design.
    >>
    >> I have a lot of sympathy for purity, but I find your call to it
    >> a litte surprizing. I thought you were in the process of moving
    >> from VHDL to Verilog for practical reasons :) ?

    >
    > I won't say the intent was "for practical reasons". It is more that I
    > want to find out for myself what is good and bad about Verilog and
    > possibly be more compatible with customers. I don't have a need for
    > "purity" and I don't think I said that.


    Agreed, you complained about the consequences of VHDL's strong
    typing system. But that's what I intended to refer to also.

    > HDLs are designed to be
    > implementation independent unless you want to specify an
    > implementation. Integers in VHDL are not intended to specify
    > implementation, while signed and unsigned are. Is being
    > implementation independent the same as being "pure"?


    That's what I mean, yes: strong typing and abstract types without
    an implied representation, such as VHDL's boolean, enum and
    integer. I'm personally all for it in general, but not for the
    case of integer. Sometimes practicality beats purity.

    > Besides, I explained how integers can be treated as bit vectors with
    > two choices. You just need to define your own functions for it.


    Note that you would have to make a choice how to represent integers
    in those functions. I wonder what that choice would be :)

    Jan

    --
    Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com
     
    Jan Decaluwe, Nov 5, 2010
    #14
  15. whygee

    Andy Guest

    The VHDL standard has already adopted an assumed two's complement
    numeric representation for vectors (numeric_std, numeric_std_unsigned,
    ufixed/sfixed, etc.) Why can we not adopt an assumed two's complement
    representation for integes as well?!

    The primary problem with vhdl vector based arithmetic (numeric_*) is
    that it rolls over (not to signed, but what's the difference, an
    unsigned rollover is still inaccurate). Take two unsigned, add them
    together, and you can get a result that is less than either of the
    operands.

    The closest vhdl vector arithmetic comes to true integer arithmetic
    accuracy is the fixed point package types, with zero fractional bits
    declared. Fixed point operators automatically pad the result size to
    account for accuracy in all cases, except one: a ufixed minus a ufixed
    is still a ufixed (but actually bigger by one bit! go figure) rather
    than an sfixed. With the almost universal need to resize sfixed/ufixed
    results to fit in an assigned signal/variable, the conversion from
    sfixed to ufixed could easily be handled in the resize function
    anyway.

    Or better yet, allow assignment operators to be overloaded so that
    they can do the resizing automatically.

    Hey, I can dream, can't I?

    Andy
     
    Andy, Nov 8, 2010
    #15
  16. whygee

    JimLewis Guest

    > The VHDL standard has already adopted an assumed two's complement
    > numeric representation for vectors (numeric_std, numeric_std_unsigned,
    > ufixed/sfixed, etc.) Why can we not adopt an assumed two's complement
    > representation for integes as well?!


    It certainly would be worth while to entertain enhancements to
    integers
    in the next revision of VHDL - I have heard others issues in addition
    to this one.

    See my separate post about study group formation. The first baby step
    toward the next standard - but it is important to attend and voice
    an opinion on the issues mentioned.


    > The closest vhdl vector arithmetic comes to true integer arithmetic
    > accuracy is the fixed point package types, with zero fractional bits
    > declared. Fixed point operators automatically pad the result size to
    > account for accuracy in all cases, except one: a ufixed minus a ufixed
    > is still a ufixed (but actually bigger by one bit! go figure) rather
    > than an sfixed. With the almost universal need to resize sfixed/ufixed
    > results to fit in an assigned signal/variable, the conversion from
    > sfixed to ufixed could easily be handled in the resize function
    > anyway.


    I think both have issues. For example:
    signal A_ufixed8, B_ufixed8, C_ufixed8, D_ufixed8 : ufixed(7 downto
    0) ;
    signal Y_ufixed11 : ufixed(10 downto 0) ;
    Y_ufixed11 <= A_ufixed8 + B_ufixed8 + C_ufixed8 + D_ufixed8 ;

    results in a different size than:
    signal A_ufixed8, B_ufixed8, C_ufixed8, D_ufixed8 : ufixed(7 downto
    0) ;
    signal Y_ufixed10 : ufixed(9 downto 0) ;
    Y_ufixed10 <= (A_ufixed8 + B_ufixed8) + (C_ufixed8 + D_ufixed8) ;


    > Or better yet, allow assignment operators to be overloaded so that
    > they can do the resizing automatically.

    It would be an interesting proposal. If it gets approved, are you
    interested in writing it? Can you formulate something that
    chooses between modulo math (like unsigned/signed) or full precision
    arith
    (like ufixed/sfixed)? If you blow the doors open and allow anything,
    I
    would think that is bad. If you add more saftey such as enforcement
    of
    ranges for ufixed/sfixed (so that more than size is enforced) then it
    would
    be exciting.

    Best,
    Jim
     
    JimLewis, Nov 8, 2010
    #16
  17. whygee

    rickman Guest

    On Nov 5, 1:23 pm, Jan Decaluwe <> wrote:
    > rickman wrote:
    > > On Nov 5, 10:09 am, Jan Decaluwe <> wrote:
    > >> rickman wrote:
    > >>> On Nov 5, 5:20 am, Jan Decaluwe <> wrote:
    > >>>> I think a language like Python does it right. Integers are true integers,
    > >>>> but through the boolean operators you have access to the underlying
    > >>>> 2's complement representation if desired.
    > >>> But that is the problem.  Who says an integer is implemented as a 2's
    > >>> complement binary signal array?
    > >> The Python Language LRM of course. It's not an axioma. Other definitions
    > >> and languages are perfectly feasible, although less practical probably..

    >
    > > That's great, but not useful for hardware design is it?

    >
    > I don't see what you are referring to here. It can't be Python/MyHDL's
    > actual choice, because that is the same as VHDL/Verilog for signed, and
    > probably any VHDL synthesis tool for integer.


    I think I have no idea what you are saying with this. What Python
    does with integers has no bearing on what VHDL does. So what is your
    point about mentioning Python?


    > >> I have a lot of sympathy for purity, but I find your call to it
    > >> a litte surprizing. I thought you were in the process of moving
    > >> from VHDL to Verilog for practical reasons :) ?

    >
    > > I won't say the intent was "for practical reasons".  It is more that I
    > > want to find out for myself what is good and bad about Verilog and
    > > possibly be more compatible with customers.  I don't have a need for
    > > "purity" and I don't think I said that.

    >
    > Agreed, you complained about the consequences of VHDL's strong
    > typing system. But that's what I intended to refer to also.


    Again, I have no idea why you are bringing this up. How does it
    pertain to the discussion?


    > > HDLs are designed to be
    > > implementation independent unless you want to specify an
    > > implementation.  Integers in VHDL are not intended to specify
    > > implementation, while signed and unsigned are.  Is being
    > > implementation independent the same as being "pure"?

    >
    > That's what I mean, yes: strong typing and abstract types without
    > an implied representation, such as VHDL's boolean, enum and
    > integer. I'm personally all for it in general, but not for the
    > case of integer. Sometimes practicality beats purity.


    Ok, you have stated your preference, but you have not given any basis
    for it. In general a given type does not have an representation
    implied so that it can be implemented in the manner that suits the
    application the best. Although 2's complement is pretty universal, it
    is not the only way to use integers. Do you think it is worth
    eliminating the use of integers for any other representation by
    specifying one representation in the standard? I guess I know the
    answer to that one. But you can see where this is a problem for some
    usage that others may want, no? Besides, the OP can do what he wants
    and perform bit wise operations on integers. He just has to write a
    few functions to do that.


    > > Besides, I explained how integers can be treated as bit vectors with
    > > two choices.  You just need to define your own functions for it.

    >
    > Note that you would have to make a choice how to represent integers
    > in those functions. I wonder what that choice would be :)


    That is up to the author to suit their application. I can see where
    they would choose to use 2's complement or unsigned possibly. It
    depends on how they intend to use it in the application.

    Rick
     
    rickman, Nov 9, 2010
    #17
  18. whygee

    Jan Decaluwe Guest

    rickman wrote:
    > On Nov 5, 1:23 pm, Jan Decaluwe <> wrote:
    >> rickman wrote:
    >>> On Nov 5, 10:09 am, Jan Decaluwe <> wrote:
    >>>> rickman wrote:
    >>>>> On Nov 5, 5:20 am, Jan Decaluwe <> wrote:
    >>>>>> I think a language like Python does it right. Integers are true integers,
    >>>>>> but through the boolean operators you have access to the underlying
    >>>>>> 2's complement representation if desired.
    >>>>> But that is the problem. Who says an integer is implemented as a 2's
    >>>>> complement binary signal array?
    >>>> The Python Language LRM of course. It's not an axioma. Other definitions
    >>>> and languages are perfectly feasible, although less practical probably.
    >>> That's great, but not useful for hardware design is it?

    >> I don't see what you are referring to here. It can't be Python/MyHDL's
    >> actual choice, because that is the same as VHDL/Verilog for signed, and
    >> probably any VHDL synthesis tool for integer.

    >
    > I think I have no idea what you are saying with this. What Python
    > does with integers has no bearing on what VHDL does. So what is your
    > point about mentioning Python?


    I try to convince people to take a good look at Python/MyHDL integers
    and possibly consider to do it similarly in a future VHDL standard.

    >>>> I have a lot of sympathy for purity, but I find your call to it
    >>>> a litte surprizing. I thought you were in the process of moving
    >>>> from VHDL to Verilog for practical reasons :) ?
    >>> I won't say the intent was "for practical reasons". It is more that I
    >>> want to find out for myself what is good and bad about Verilog and
    >>> possibly be more compatible with customers. I don't have a need for
    >>> "purity" and I don't think I said that.

    >> Agreed, you complained about the consequences of VHDL's strong
    >> typing system. But that's what I intended to refer to also.

    >
    > Again, I have no idea why you are bringing this up. How does it
    > pertain to the discussion?


    The ideas I'm proposing would solve many of the VHDL usability
    issues that we are all struggling with, including the OP and
    you as I understood it, when you announced that you'd rather
    switch (to Verilog) than fight (with VHDL).

    >>> HDLs are designed to be
    >>> implementation independent unless you want to specify an
    >>> implementation. Integers in VHDL are not intended to specify
    >>> implementation, while signed and unsigned are. Is being
    >>> implementation independent the same as being "pure"?

    >> That's what I mean, yes: strong typing and abstract types without
    >> an implied representation, such as VHDL's boolean, enum and
    >> integer. I'm personally all for it in general, but not for the
    >> case of integer. Sometimes practicality beats purity.

    >
    > Ok, you have stated your preference, but you have not given any basis
    > for it. In general a given type does not have an representation
    > implied so that it can be implemented in the manner that suits the
    > application the best. Although 2's complement is pretty universal, it
    > is not the only way to use integers. Do you think it is worth
    > eliminating the use of integers for any other representation by
    > specifying one representation in the standard? I guess I know the
    > answer to that one. But you can see where this is a problem for some
    > usage that others may want, no?


    No, I don't think there is a problem.

    Imagine an integer type with an "accessible" 2's complement representation.
    A synthesis tool only has to honour that when the representation is
    actually "accessed" in the code, something which is easy for a tool to
    detect. Otherwise, it could implement it with any optimized representation it
    chooses. The latter case is equivalent to the current situation, with an
    "inaccessible" representation. In other words, this would be a backwards
    compatible enhancement.

    If you need full control over representation, you'd have to do it like
    today: use bit vectors with dedicated logic, and interprete the bit
    vector values as numbers yourself.

    Jan

    --
    Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com
     
    Jan Decaluwe, Nov 9, 2010
    #18
  19. whygee

    rickman Guest

    On Nov 9, 4:06 am, Jan Decaluwe <> wrote:
    > rickman wrote:
    > > On Nov 5, 1:23 pm, Jan Decaluwe <> wrote:
    > >> I don't see what you are referring to here. It can't be Python/MyHDL's
    > >> actual choice, because that is the same as VHDL/Verilog for signed, and
    > >> probably any VHDL synthesis tool for integer.

    >
    > > I think I have no idea what you are saying with this.  What Python
    > > does with integers has no bearing on what VHDL does.  So what is your
    > > point about mentioning Python?

    >
    > I try to convince people to take a good look at Python/MyHDL integers
    > and possibly consider to do it similarly in a future VHDL standard.
    >
    > >> Agreed, you complained about the consequences of VHDL's strong
    > >> typing system. But that's what I intended to refer to also.

    >
    > > Again, I have no idea why you are bringing this up.  How does it
    > > pertain to the discussion?

    >
    > The ideas I'm proposing would solve many of the VHDL usability
    > issues that we are all struggling with, including the OP and
    > you as I understood it, when you announced that you'd rather
    > switch (to Verilog) than fight (with VHDL).


    I don't see where it would solve the problems I have seen unless it
    allows the use of integers to replace all data types... I tried using
    Boolean for some control signals as this simplifies expressions in
    conditionals. But in simulation Boolean signals are displayed as a
    value like an integer which is a PITA. A std_logic signal is
    displayed as a line with two levels and is very easy to see rather
    than having to read a value which can be off the display.


    > >> That's what I mean, yes: strong typing and abstract types without
    > >> an implied representation, such as VHDL's boolean, enum and
    > >> integer. I'm personally all for it in general, but not for the
    > >> case of integer. Sometimes practicality beats purity.

    >
    > > Ok, you have stated your preference, but you have not given any basis

    ccc> > for it.  In general a given type does not have an
    representation
    > > implied so that it can be implemented in the manner that suits the
    > > application the best.  Although 2's complement is pretty universal, it
    > > is not the only way to use integers.  Do you think it is worth
    > > eliminating the use of integers for any other representation by
    > > specifying one representation in the standard?  I guess I know the
    > > answer to that one.  But you can see where this is a problem for some
    > > usage that others may want, no?

    >
    > No, I don't think there is a problem.
    >
    > Imagine an integer type with an "accessible" 2's complement representation.
    > A synthesis tool only has to honour that when the representation is
    > actually "accessed" in the code, something which is easy for a tool to
    > detect. Otherwise, it could implement it with any optimized representation it
    > chooses. The latter case is equivalent to the current situation, with an
    > "inaccessible" representation. In other words, this would be a backwards
    > compatible enhancement.
    >
    > If you need full control over representation, you'd have to do it like
    > today: use bit vectors with dedicated logic, and interprete the bit
    > vector values as numbers yourself.


    I don't need control over the representation of integers. But my tool
    vendor may need that. The synthesis tool is designed for the target.
    If it works better to represent integers as signed magnitude then the
    synthesis tool can do that without my involvement or knowledge. How
    would you allow a synthesis tool to optimize for a given target
    implementation if the representation is fixed? By requiring the tool
    to work one way when the bit representation is accessed and a
    different way when it is not sounds like a complexity that could cause
    problems for users.

    Maybe that is not really important. I know it is an issue in the
    software world, but in FPGAs and ASICs I can't think of an example
    where the number representation is anything other than 2's
    complement. But I don't see it helping with any problems unless you
    can replace all data types with integers.

    Rick
     
    rickman, Nov 9, 2010
    #19
  20. whygee

    Andy Guest

    On Nov 8, 12:53 pm, JimLewis <> wrote:
    > > The closest vhdl vector arithmetic comes to true integer arithmetic
    > > accuracy is the fixed point package types, with zero fractional bits
    > > declared. Fixed point operators automatically pad the result size to
    > > account for accuracy in all cases, except one: a ufixed minus a ufixed
    > > is still a ufixed (but actually bigger by one bit! go figure) rather
    > > than an sfixed. With the almost universal need to resize sfixed/ufixed
    > > results to fit in an assigned signal/variable, the conversion from
    > > sfixed to ufixed could easily be handled in the resize function
    > > anyway.

    >
    > I think both have issues.  For example:
    > signal A_ufixed8, B_ufixed8, C_ufixed8, D_ufixed8 : ufixed(7 downto
    > 0) ;
    > signal Y_ufixed11 : ufixed(10 downto 0) ;
    > Y_ufixed11 <= A_ufixed8 + B_ufixed8 + C_ufixed8 + D_ufixed8 ;
    >
    > results in a different size than:
    > signal A_ufixed8, B_ufixed8, C_ufixed8, D_ufixed8 : ufixed(7 downto
    > 0) ;
    > signal Y_ufixed10 : ufixed(9 downto 0) ;
    > Y_ufixed10 <= (A_ufixed8 + B_ufixed8) + (C_ufixed8 + D_ufixed8) ;


    If you used y_ufixed10 <= resize(expr, y_ufixed10); it wouldn't make
    any difference, no matter which form of the expression you used. I
    find it very seldom that you do not have to use a resize function
    prior to an assignment with the fixed point packages, which is why
    overloading the assignment operator to include the resize
    functionality makes a lot of sense. Again, this would work very
    similarly to the way integer expressions and assignments work, but
    without the limitations of size in integer.

    >
    > > Or better yet, allow assignment operators to be overloaded so that
    > > they can do the resizing automatically.

    >
    > It would be an interesting proposal. If it gets approved, are you
    > interested in writing it?  


    I don't have any compiler writing experience, so defining the syntax
    to use for overloading an assignment operator, and limiting its use to
    cases that are reasonable to implement would be beyond me. But I am
    certainly willing to help where I can (defining what we want to be
    able to do).

    > Can you formulate something that
    > chooses between modulo math (like unsigned/signed) or full precision
    > arith
    > (like ufixed/sfixed)?  If you blow the doors open and allow anything,
    > I
    > would think that is bad.  If you add more saftey such as  enforcement
    > of
    > ranges for ufixed/sfixed (so that more than size is enforced) then it
    > would
    > be exciting.


    Allowing blanket overloading of assignment operators would necessarily
    "blow the doors off".

    Perhaps restricting overloaded assignment operators to be defined in
    the same declarative region as the type to which they assign would
    help, especially in the case of the standard packages (users could not
    re-overload the assignment operators outside the package).

    An overloaded assignment operator for vectors, unlike a standard
    operator, would have to be able to know what the target range is,
    which is not currently possible for a function in vhdl. So it would
    have to be handled more like a procedure with an in and out argument,
    unless we developed some whole new syntax.

    It would not be the assignment operator which would define modulo
    (roll-over) math vs full-precision. That is controlled by the type,
    and those operators that are defined for the type. The assignment
    operator could define behavior like truncate, saturate, round, etc.
    when assigning a larger vector into a smaller one.

    On the other hand, we would not need overloaded assignment operators
    (and all of their potential pitfalls blowing doors off) if we had an
    arbitrarily sized type of integer, including fixed point capability
    and bit-wise logical operations defined. Then there would be no
    overloaded assignment operators and all their potential pitfalls to
    deal with.

    Andy
     
    Andy, Nov 10, 2010
    #20
    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. Jesus M. Salvo Jr.
    Replies:
    2
    Views:
    4,326
    robert
    Feb 11, 2006
  2. Flavio

    boolean operations on sets

    Flavio, Aug 6, 2007, in forum: Python
    Replies:
    7
    Views:
    279
    Bruno Desthuilliers
    Aug 7, 2007
  3. J Leonard
    Replies:
    4
    Views:
    12,891
    Mark Space
    Jan 19, 2008
  4. Amal
    Replies:
    1
    Views:
    1,788
    vipinlal
    Mar 4, 2010
  5. Metre Meter
    Replies:
    7
    Views:
    462
    Metre Meter
    Aug 6, 2010
Loading...

Share This Page