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

 

[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 !

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

 

[backhus]

Hi !



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

 

[Tricky]

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.

 

[Jan Decaluwe]

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

 

[rickman]

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]

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.

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.
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.
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 ?
yes, so what ?
data is data.
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) ?
haha
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.

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

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

 

[rickman]

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?

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]

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

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

 

[Jan Decaluwe]

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]

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

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

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?

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?

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.

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]

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.

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

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

 

[rickman]

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.



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.

ccc> > for it.  In general a given type does not have an
representation

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

 

[Andy]

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.

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