boolean operations on "integer" in VHDL'93

Yes, if the designer wants to consider SLV as a 2's complement vector,
there is nothing in the language to prevent that.  But there is
nothing in the language to promote it either.  Anyone is free to
create their own libraries or to use standard ones to add capabilities
to the language.  That is what is going on in both
numeric_std_unsigned and in numeric_std.  The utility of these data
types is being extended as the designer wishes.  It is not a default
part of the language.

How do you expect a synthesis tool to handle this requirement?  If you
write VHDL code to increment a counter, what do you expect the
hardware to do when the counter reaches the max value?  Are you saying
you expect the synthesis tool to throw an error if the designer does
not indicate explicitly what will happen with an IF statement or a MOD
operator?

What does the synthesis tool do with integers in the case of a counter
that can overflow?

signal a : integer range 0 to 15;
-- clocked process wrapper...
  a <= a + 1;

What hardware should this produce?  Or how should I write this for a 4
bit counter?  How exactly should the synthesis tool "die trying"?

On Nov 11, 3:33 pm, rickman <gnu...@gmail.com> wrote:
On Nov 8, 12:57 pm, Andy <jonesa...@comcast.net> wrote:

So maybe we limit the actions of overloaded assignment operators to
converting "closely related" types and resizing to this relatively
safe. If it works out, maybe we can extend overloaded assignments to
other areas, but I'd rather take baby steps and not break anything,
than take too big a step and cause bigger, unforseen problems.

Before you go too far with overloaded assignment operators,
you have to face another issue :

assignment is not an operator!

And changing that in VHDL would probably be difficult (for a mild
understatement). For better or worse, it's a 50-year old design decision in,
clearly not just VHDL, but back through Ada, and right back to Algol-60.

I don't see it happening.

On Nov 12, 9:58 am, rickman <gnu...@gmail.com> wrote:

Yes, if the designer wants to consider SLV as a 2's complement vector,
there is nothing in the language to prevent that. But there is
nothing in the language to promote it either. Anyone is free to
create their own libraries or to use standard ones to add capabilities
to the language. That is what is going on in both
numeric_std_unsigned and in numeric_std. The utility of these data
types is being extended as the designer wishes. It is not a default
part of the language.

The standard ("default part of the") language now includes the
packages. And by allowing the unsigned(my_slv) conversion, which does
not include any reforming of the elements within my_slv, and my_slv =
10 (via numeric_std_unsigned), the language is ensuring that the
numeric interpretation is extended to slv. Whether you choose to
access that interpretation or not, the representation must be
consistent with the numeric interpretation.



How do you expect a synthesis tool to handle this requirement? If you
write VHDL code to increment a counter, what do you expect the
hardware to do when the counter reaches the max value? Are you saying
you expect the synthesis tool to throw an error if the designer does
not indicate explicitly what will happen with an IF statement or a MOD
operator?

What does the synthesis tool do with integers in the case of a counter
that can overflow?

signal a : integer range 0 to 15;
-- clocked process wrapper...
a <= a + 1;

What hardware should this produce? Or how should I write this for a 4
bit counter? How exactly should the synthesis tool "die trying"?

Your description did not legally tell the synthesis tool what to do
when a is 15, since storing the result of 15 + 1 in a would be illegal
(and in fact impossible in a four bit storage register). Therefore,
the synthesis tool is free to do anything it wants in that case.

So, one way to look at what really happens in synthesis is this:

signal a : integer range 0 to 15;
-- clocked process wrapper...
if a + 1 > 15 then -- implied by the range of a
a <= "don't care"; -- because assigning 16 to a is illegal anyway
else
a <= a + 1;
end if;

Lucky for us, it turns out that the most efficient implementation of
the above is to simply truncate the result of 15 + 1, which is a roll
over, or modulo counter.

I would prefer that it at least give me a warning that it was doing
this, but in reality, it could do anything it wants, because I did not
tell it what to do.

To keep simulation and synthesis on the same page, a better way to
write it in the first place would be:

signal a : integer range 0 to 15;
-- clocked process wrapper...
a <= (a + 1) mod 16;

This way, you are explicitly, legally telling the synthesis tool (and
the simulator) what you want to do when a is 15.

Andy

On Fri, 12 Nov 2010 06:38:15 -0800 (PST), Andy <jonesandy_at_comcast.net> wrote:

On Nov 11, 3:33 pm, rickman <gnu...@gmail.com> wrote:
On Nov 8, 12:57 pm, Andy <jonesa...@comcast.net> wrote:

So maybe we limit the actions of overloaded assignment operators to
converting "closely related" types and resizing to this relatively
safe. If it works out, maybe we can extend overloaded assignments to
other areas, but I'd rather take baby steps and not break anything,
than take too big a step and cause bigger, unforseen problems.

Before you go too far with overloaded assignment operators,
you have to face another issue :

assignment is not an operator!

And changing that in VHDL would probably be difficult (for a mild
understatement). For better or worse, it's a 50-year old design decision in,
clearly not just VHDL, but back through Ada, and right back to Algol-60.

I don't see it happening.