boolean operations on "integer" in VHDL'93

Thu Nov 04, 2010 12:28 pm   

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

Thu Nov 04, 2010 9:37 pm   

On Thu, 04 Nov 2010 12:28:31 +0100, whygee <yg_at_yg.yg> wrote:


bit_vector should be less heavyweight than std_logic_vector.

- Brian

Thu Nov 04, 2010 11:13 pm   

Le 04/11/2010 12:28, whygee a écrit :

That's strong typing for you...

Nicolas

Fri Nov 05, 2010 5:30 am   

Hi !

Brian Drummond wrote:



Nicolas Matringe wrote :

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 ?


--
http://ygdes.com / http://yasep.org

Fri Nov 05, 2010 9:24 am   

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

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

Fri Nov 05, 2010 10:05 am   

On Fri, 05 Nov 2010 05:30:12 +0100, whygee <yg_at_yg.yg> 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.

(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

Fri Nov 05, 2010 10:20 am   

Brian Drummond wrote:


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

Fri Nov 05, 2010 10:32 am   

On Nov 4, 11:28 am, whygee <y...@yg.yg> wrote:

Use signed/unsigned instead? you can do arithmatic and boolean with
them.

Fri Nov 05, 2010 1:24 pm   

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

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


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

Fri Nov 05, 2010 3:09 pm   

rickman wrote:

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


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

Fri Nov 05, 2010 3:34 pm   

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:

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.


does the job fastest Don't worry : std_ulogic is not going to be thrown away,
or else, how will i synthesise my code ?


data is data.



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) ?




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.


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 :-)


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




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,


--
http://ygdes.com / http://yasep.org

Fri Nov 05, 2010 4:55 pm   

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

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



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

Fri Nov 05, 2010 5:13 pm   

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

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

Fri Nov 05, 2010 5:40 pm   

Tricky wrote:


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

Fri Nov 05, 2010 6:44 pm   

rickman 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.


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


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,


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