simple stuff !!!

[LC]

Hi,

I have some code where it is quite convenient
to treat the integers as std_logic_vectors for bit manipulations
wile on other places arithmetics are necessary.

I can't use aa(7) of signal aa in integer
and can't "aa+bb" in std_logic vectors
using conv_etc... functions the code becomes a complete
mess...

What I'm I missing...

Any help.


luis c.

 

[KJ]

Hi,

I have some code where it is quite convenient
to treat the integers as std_logic_vectors for bit manipulations
wile on other places arithmetics are necessary.

I can't use aa(7) of signal aa in integer
and can't "aa+bb" in std_logic vectors
using conv_etc... functions the code becomes a complete
mess...

What I'm I missing...

Any help.

luis c.

Use ieee.numeric_std library and use signed/unsigned instead of
std_logic_vector.

Kevin Jennings

 

[LC]

Thanks, I'm using it now,
and found some other issues:

signal aa,bb: unsigned(7 downto 0);
....
aa <= 2; !!!!! says wrong literal
aa <= "00000010" appears to work !!!

so, I have no clue how can assign a signal to
a constant value in decimal.


also could not find a way of adding

bb <= aa + f;

being f a bit. tried many types and ways.
this I may solve with an if but for a
more complex expression becomes messy.

Sorry for this basic issues

But I have worked all my life with
std_logic and integers only ;-)


Thanks, for the kind help.

Luis C.

 

[Mike Treseler]

signal aa,bb: unsigned(7 downto 0);
...
aa <= 2; !!!!! says wrong literal
aa <= "00000010" appears to work !!!

so, I have no clue how can assign a signal to
a constant value in decimal.

aa <= to_unsigned(2, 8);

also could not find a way of adding

bb <= aa + f;

being f a bit.

Well if f is std_logic, I could say:

Sorry for this basic issues

Basic, but not obvious.

-- Mike Treseler

__________________________________________
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity uns_dec is
end uns_dec;

architecture sim of uns_dec is
constant one : unsigned := x"01";
constant two : unsigned := x"02";
constant f : std_ulogic := '1';
begin
p : process is
variable aa, bb: unsigned(7 downto 0);
begin
aa := to_unsigned(2, 8);
assert aa = 2;
aa := x"02";
assert aa = 2;
aa := "00000010";
assert aa = 2;
aa := x"00" + 2;
assert aa = 2;
aa := two;
assert aa = 2;
aa := two - one + 1;
assert aa = 2;
bb := aa + (0 => f);
assert bb = 3;
report("No assertions expected above");
wait;
end process p;
end sim;

-- # vsim -c uns_dec
-- VSIM 1> run
-- # ** Note: No assertions expected above
-- # Time: 0 ns Iteration: 0 Instance: /uns_dec

 

[LC]

Mike,
Excellent. Super Thanks.
This really keeps me going.

damn habits of doing the same things
over and over that keeps me from widening
my knowledge.

Luis C.

 

[Guest]

aa <= to_unsigned(2, 8);

I'm sure Mike won't be offended if I point out
this alternative, which I prefer:

aa <= to_unsigned(2, aa'length);

Well if f is std_logic, I could say:
bb <= aa + (0 => f);

Another nit-pick: If bb and aa are UNSIGNED, then
Mike's solution is perfect. But if they are SIGNED,
you will get some nasty surprises - a single-bit
SIGNED vector represents either 0 or -1 !!! So
it might be better to do

bb <= aa + signed'("0" & f);

Note, also, that if you do this sort of thing
a lot it may be a good idea to write overloaded
arithmetic operators for yourself:

function "+" (L: signed; R: std_logic) return signed
is begin
assert L'length > 1
report "Single-bit SIGNED can harm your sanity"
severity ERROR;
return L + signed'("0" & R);
end;

 

[rickman]

Jon,


But put this in a temporary package as it is in the
next revision of the language.

Can it be expected any time in the future that

signal aa : unsigned(7 downto 0);
aa <= 3;

will be supported? It just seems pretty obvious what is meant by
that.

 

[Mike Treseler]

Can it be expected any time in the future that

signal aa : unsigned(7 downto 0);
aa <= 3;

will be supported? It just seems pretty obvious what is meant by
that.

aa <= 256;

 

[Guest]

Can it be expected any time in the future that

signal aa : unsigned(7 downto 0);
aa <= 3;

will be supported? It just seems pretty obvious what is meant by
that.

Obvious to us, but not inherent in the definitions, I think.

I have long argued that VHDL would greatly benefit from
the ability to overload the assignment operation ":=".
This would allow specialised data types to do all kinds of
intelligent resizing, type conversion and so on. For
your example, I would want the numeric_std package to
incorporate this:

procedure ":=" (target: out unsigned; source: in integer) is
begin
target := to_unsigned(source, target'length);
end;

There would be no need, nor desire, to overload signal
assignment; its behaviour would follow the equivalent
variable assignment, together with all the existing
built-in signal assignment semantics.

There's just one, easily-fixed, wrinkle: The body of any
overloaded ":=" procedure will surely include some assignments.
To avoid circular definition problems, it would be necessary
to appeal to the built-in definition of := (target and source
checked for type equivalence by the compiler; array subtypes
checked for width equivalence at run time). For example,
a version of SIGNED that auto-resizes on assignment to fit
its target:

procedure ":=" (target: out signed; source: in signed) is
begin
std.standard.":="(target, resize(source, target'length));
end;

There are a few places in the language where there is an
implicit copy operation (copying of actual expression value
to a subprogram's "in" or "inout" formal, for example). The
overloaded := would also apply in such situations. Also,
the test expression in an "if" or "assert" could be regarded
as an implied copy from the actual expression to an implicit
boolean variable; in this way, overloading := for boolean
targets would allow you to get "if some_std_logic then"...
in a consistent and flexible way.

~~~~~~~~~~~~~~

Is this, or something like it, already on the table for
the current round of VHDL extensions?
Am I alone in thinking this might be a good idea?

 

[Mike Treseler]

I have long argued that VHDL would greatly benefit from
the ability to overload the assignment operation ":=".
This would allow specialised data types to do all kinds of
intelligent resizing, type conversion and so on. For
your example, I would want the numeric_std package to
incorporate this:

procedure ":=" (target: out unsigned; source: in integer) is
begin
target := to_unsigned(source, target'length);
end;

The language does need that feature.

Is this, or something like it, already on the table for
the current round of VHDL extensions?
Am I alone in thinking this might be a good idea?

It's a good idea. Consider submitting it.
Even if something like that is in the works,
that is a clear description of the requirement.

-- Mike Treseler

 

[KJ]

Obvious to us, but not inherent in the definitions, I think.

I have long argued that VHDL would greatly benefit from
the ability to overload the assignment operation ":=".
This would allow specialised data types to do all kinds of
intelligent resizing, type conversion and so on.  For
your example, I would want the numeric_std package to
incorporate this:

  procedure ":=" (target: out unsigned; source: in integer) is
  begin
    target := to_unsigned(source, target'length);
  end;

There would be no need, nor desire, to overload signal
assignment; its behaviour would follow the equivalent
variable assignment, together with all the existing
built-in signal assignment semantics.

There's just one, easily-fixed, wrinkle:  The body of any
overloaded ":=" procedure will surely include some assignments.
To avoid circular definition problems, it would be necessary
to appeal to the built-in definition of := (target and source
checked for type equivalence by the compiler; array subtypes
checked for width equivalence at run time).  For example,
a version of SIGNED that auto-resizes on assignment to fit
its target:

  procedure ":=" (target: out signed; source: in signed) is
  begin
    std.standard.":="(target, resize(source, target'length));
  end;

There are a few places in the language where there is an
implicit copy operation (copying of actual expression value
to a subprogram's "in" or "inout" formal, for example).  The
overloaded := would also apply in such situations.  Also,
the test expression in an "if" or "assert" could be regarded
as an implied copy from the actual expression to an implicit
boolean variable; in this way, overloading := for boolean
targets would allow you to get "if some_std_logic then"...
in a consistent and flexible way.

~~~~~~~~~~~~~~

Is this, or something like it, already on the table for
the current round of VHDL extensions?
Am I alone in thinking this might be a good idea?

No you're not alone, I've grumbled about it too. But now that you've
written up a good description, copy/paste it to http://www.eda-stds.org/vasg/bugrep.htm
and then it will be on the table for consideration whether it's there
already or not.

Kevin Jennings

 

[rickman]

aa <= 256;

What is that supposed to mean? I don't have my decoder ring handy.

 

[Mike Treseler]

What is that supposed to mean? I don't have my decoder ring handy.

I think your example for '3' makes sense
but the same example for 256 is ambiguous
for an 8 bit vector.

-- Mike Treseler

 

[rickman]

I think your example for '3' makes sense
but the same example for 256 is ambiguous
for an 8 bit vector.

-- Mike Treseler

Duh...

There are any number of ways to misuse a language. I don't really see
your point.

Rick