boolean operations on "integer" in VHDL'93

[whygee]

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

 

[Brian Drummond]

On Thu, 04 Nov 2010 12:28:31 +0100, whygee <yg@yg.yg> 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 ?

bit_vector should be less heavyweight than std_logic_vector.

- Brian

 

[Nicolas Matringe]

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

 

[whygee]

Hi !

Brian Drummond wrote:

On Thu, 04 Nov 2010 12:28:31 +0100, whygee <yg@yg.yg> 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

 

[backhus]

On 5 Nov., 05:30, whygee <y...@yg.yg> wrote:

Hi !

Brian Drummond wrote:
On Thu, 04 Nov 2010 12:28:31 +0100, whygee <y...@yg.yg> 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

 

[Brian Drummond]

On Fri, 05 Nov 2010 05:30:12 +0100, whygee <yg@yg.yg> wrote:

Hi !

Brian Drummond wrote:
On Thu, 04 Nov 2010 12:28:31 +0100, whygee <yg@yg.yg> 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 ?

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.

(If you think this is a little OTT, just count the number of "integer overflow"
bugs reported in a project like Firefox. And weep.)

- Brian

 

[Jan Decaluwe]

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

 

[Tricky]

On Nov 4, 11:28 am, whygee <y...@yg.yg> 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.

 

[rickman]

On Nov 5, 5:20 am, Jan Decaluwe <j...@jandecaluwe.com> 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

 

[Jan Decaluwe]

rickman wrote:

On Nov 5, 5:20 am, Jan Decaluwe <j...@jandecaluwe.com> 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

 

[whygee]

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 <j...@jandecaluwe.com> 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

 

[rickman]

On Nov 5, 10:09 am, Jan Decaluwe <j...@jandecaluwe.com> wrote:

rickman wrote:
On Nov 5, 5:20 am, Jan Decaluwe <j...@jandecaluwe.com> 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

 

[Tricky]

On Nov 5, 2:09 pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:

rickman wrote:
On Nov 5, 5:20 am, Jan Decaluwe <j...@jandecaluwe.com> 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?

 

[Jan Decaluwe]

Tricky wrote:

Can you explain to me why you should use intbv over signed/unsigned?

Because it makes integer arithmetic work like God intended it

--
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]

rickman wrote:

On Nov 5, 10:09 am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
rickman wrote:
On Nov 5, 5:20 am, Jan Decaluwe <j...@jandecaluwe.com> 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]

rickman wrote:

On Nov 5, 10:09 am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
rickman wrote:
On Nov 5, 5:20 am, Jan Decaluwe <j...@jandecaluwe.com> 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

 

[Andy]

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

 

[JimLewis]

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

 

[rickman]

On Nov 5, 1:23 pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:

rickman wrote:
On Nov 5, 10:09 am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
rickman wrote:
On Nov 5, 5:20 am, Jan Decaluwe <j...@jandecaluwe.com> 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

 

[Jan Decaluwe]

rickman wrote:

On Nov 5, 1:23 pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:
rickman wrote:
On Nov 5, 10:09 am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
rickman wrote:
On Nov 5, 5:20 am, Jan Decaluwe <j...@jandecaluwe.com> 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