simple stuff !!!

L

LC

Guest
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.
 
On May 14, 2:26 pm, LC <cupidoREM...@mail.ua.pt> wrote:
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
 
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.



KJ wrote:
On May 14, 2:26 pm, LC <cupidoREM...@mail.ua.pt> wrote:

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

Kevin Jennings
 
LC wrote:

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:
bb <= aa + (0 => f);

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



Mike Treseler wrote:
LC wrote:

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:
bb <= aa + (0 => f);

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
 
On May 15, 6:30 am, Mike Treseler wrote:

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

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

also could not find a way of adding
bb <= aa + f;
being f a bit.

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;

--
Jonathan Bromley
 
Jon,
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;
But put this in a temporary package as it is in the
next revision of the language.

Cheers,
Jim
 
On May 15, 7:42 pm, Jim Lewis <j...@synthworks.com> wrote:
Jon,

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;

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

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;
 
On May 16, 4:13 am, rickman wrote:

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?
--
Jonathan Bromley
 
spam@oxfordbromley.plus.com wrote:

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
 
rickman wrote:
On May 15, 7:42 pm, Jim Lewis <j...@synthworks.com> wrote:
Jon,

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;
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.
I haven't seen anything. :)

There will be:
aa <= 8D"3" ;

Where D is for decimal string literals.

The problem with integers is there is no way to infer anything
about the size. Personally I think we get a lot of value out
of sized arrays.

Jim
 
On May 16, 4:23 am, s...@oxfordbromley.plus.com wrote:
On May 16, 4:13 am, rickman wrote:

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?
--
Jonathan Bromley
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
 
On May 16, 2:05 am, Mike Treseler <mtrese...@gmail.com> wrote:
rickman wrote:
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;
What is that supposed to mean? I don't have my decoder ring handy.
 
rickman wrote:

aa <= 256;

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
 
On May 16, 9:42 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
rickman wrote:
aa <= 256;

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

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

Rick
 
On Fri, 16 May 2008 07:56:36 -0700 (PDT), KJ wrote:


Am I alone in thinking this
[overloadable assignment operator]
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.
Done; I'll let you know of any outcome.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 

Welcome to EDABoard.com

Sponsor

Back
Top