Addition of one

[Julian]

Hi NG.

This is more a digital design related question, hope you have an idea.
Is there a fast way of adding one (1) to any number? Is there another way
than implementing an actual complete adder structure? Could this in some way
be reduced as we now have a fixed constant to add?

Best Regards
Julian

 

[Narendran Kumaraguru Nath]

Julian wrote:

Hi NG.

This is more a digital design related question, hope you have an idea.
Is there a fast way of adding one (1) to any number? Is there another way
than implementing an actual complete adder structure? Could this in some way
be reduced as we now have a fixed constant to add?

Best Regards
Julian

Hi,
The ieee packages "std_logic_arith", "std_logic_unsigned" &
"std_logic_signed" have overloaded the "+" operator. Hence you can just
add std_logic_vectors.
Thanks & Regards,
Naren.

Narendran Kumaraguru Nathan
TooMuch Semiconductor Solutions Pvt. Ltd.
www.toomuchsemi.com
A Bangalore based startup specialising on services in EDA & Verification.

 

[Narendran Kumaraguru Nath]

Narendran Kumaraguru Nathan wrote:

Julian wrote:

Hi NG.

This is more a digital design related question, hope you have an idea.
Is there a fast way of adding one (1) to any number? Is there another way
than implementing an actual complete adder structure? Could this in
some way
be reduced as we now have a fixed constant to add?

Best Regards
Julian



Hi,
The ieee packages "std_logic_arith", "std_logic_unsigned" &
"std_logic_signed" have overloaded the "+" operator. Hence you can just
add std_logic_vectors.
Thanks & Regards,
Naren.

Narendran Kumaraguru Nathan
TooMuch Semiconductor Solutions Pvt. Ltd.
www.toomuchsemi.com
A Bangalore based startup specialising on services in EDA & Verification.

Hi Julian,

I completely misunderstood the question and answered wrongly in a hurry.

Looking at the problem of addition, if you have one input constant,
the synthesis tool 'll be able to understand that and 'll make the
synthesised circuit much simpler. Also, if you can tell us your exact
problem... probably we can give you some suggestions on making the
circuit simpler ... & one that meets timing goals etc...

Thanks & Regards,
Naren.

Narendran Kumaraguru Nathan
TooMuch Semiconductor Solutions Pvt. Ltd.
www.toomuchsemi.com
A Bangalore based startup specialising on services in EDA & Verification.

 

[Nicolas Matringe]

Jim Lewis a écrit:

On the standard horizon, there will be a numeric_unsigned
package from IEEE, however, there will not be a
numeric_signed package.

Maybe I am not an advanced user enough but I can't see what's missing in
numeric_std that would need the addition of a new package.


--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/

 

[Paul Uiterlinden]

Nicolas Matringe wrote:

Jim Lewis a écrit:

On the standard horizon, there will be a numeric_unsigned
package from IEEE, however, there will not be a
numeric_signed package.


Maybe I am not an advanced user enough but I can't see what's missing in
numeric_std that would need the addition of a new package.

The arithmetic operators are overloading only for types signed and
unsigned, not for std_logic_vector. The latter was done in package
ieee.std_logic_unsigned (by Synopsys, not IEEE).

Though this was convenient, it is actually not allowed to overload an
operator (e.g. "=") in another package (std_logic_unsigned) than where
it originally was defined (std_logic_1164, which impicitely defines an
"=" operator with the declaration of the std_logic type). Hence the
"-explicit" option in ModelSim to allow the non LRM compliant code.

With ieee.std_logic_(un)signed, you cannot mix signed and unsigned
operations in one design unit using those packages.

With ieee.numeric_std you can, because you always have to use the types
signed or unsigned for arithmetic operation on vectors.

When using an arithmetic operation on a std_logic_vector, some
conversions back and forth must be used, making the code quite lengthy:

VARIABLE a: std_logic_vector(7 DOWNTO 0);

a := std_logic_vector(unsigned(a) + 1);

That's why I think people are asking for numeric_unsigned, making it
possible to write "a := a + 1;" again.

Of course, changing the type of "a" to unsigned(7 DOWNTO 0) would
accomplish the same, but you will need a conversion again when assigning
"a" to a std_logic_vector.

Paul.

 

[Nicolas Matringe]

Paul Uiterlinden a écrit:

When using an arithmetic operation on a std_logic_vector, some
conversions back and forth must be used, making the code quite lengthy:

VARIABLE a: std_logic_vector(7 DOWNTO 0);

a := std_logic_vector(unsigned(a) + 1);

That's why I think people are asking for numeric_unsigned, making it
possible to write "a := a + 1;" again.

Of course, changing the type of "a" to unsigned(7 DOWNTO 0) would
accomplish the same, but you will need a conversion again when assigning
"a" to a std_logic_vector.

So this would only allow arithmetic operations on std_logic_vector?
Really no point, IMO

--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/

 

[Paul Uiterlinden]

Nicolas Matringe wrote:

Paul Uiterlinden a écrit:
Of course, changing the type of "a" to unsigned(7 DOWNTO 0) would
accomplish the same, but you will need a conversion again when
assigning "a" to a std_logic_vector.

So this would only allow arithmetic operations on std_logic_vector?

I'm not sure what you mean here. Operators are overloaded, so integers
(and reals) would work too.

Paul.

 

[Nicolas Matringe]

Paul Uiterlinden a écrit:

So this would only allow arithmetic operations on std_logic_vector?
I'm not sure what you mean here. Operators are overloaded, so integers
(and reals) would work too.

I meant that the purpose of this overloading is to add the possibility
of doing arithmetic operation on std_logic_vector.
I know integers and so on are still supported, as they are with numeric_std.
I don't see the point of adding such a support. Type casting may be
tedious but it is much cleaner.

--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/

 

[Jim Lewis]

Nicolas and Paul,

Maybe I am not an advanced user enough but I can't see
what's missing in numeric_std that would need the
addition of a new package.

First considering testbenches. If you have a design
where you want to apply an algorithm on an address,
you need to do unsigned math. Most ports of designs
are std_logic_vector (due to limitations of some
synthesis tools). Hence to do this, you can:

1) Use std_logic_unsigned/numeric_unsigned and
just do it.

2) Use all unsigned signals and convert them to
std_logic_vector at the instantiation.

3) Use std_logic_vector signals and do lots of
type casting.

I commonly do 1, but have been contemplating doing 2.
-------------------

For RTL design, all math should be done with numeric_std.
However, is an incrementer really math - do I really
need a type to convey what I am doing?

All implicit comparisons in VHDL are done using a
lexigraphic sort (dictionary ordering). If you are
doing comparisons, it is much safer to use a math
package (either numeric_std or the future numeric_unsigned).

For the following std_logic_vector comparisons, which
is more readable:

-- with only 1164
Y <= '1' when A = "1010" else '0' ;

-- with numeric_unsigned/std_logic_unsigned
Y <= '1' when A = 10 else '0' ;

-- with numeric_std:
Y <= '1' when unsigned(A) = 10 else '0' ;

Going further what if A increases by 1 bit, but
your forget to update your literal above?
With just std_logic_1164, the first one is still
legal, but it will not produce what you want.
With the std_logic_unsigned or the future
numeric_unsigned, both forms are still correct.
-------------------

From Paul:
Though this was convenient, it is actually not allowed to overload an
operator (e.g. "=") in another package (std_logic_unsigned) than where
it originally was defined (std_logic_1164, which impicitely defines an
"=" operator with the declaration of the std_logic type). Hence the
"-explicit" option in ModelSim to allow the non LRM compliant code.
This is being corrected. In the next rev of the LRM, explicit

operators will always override implicit operators. In fact, you
will notice that ModelSim now makes the explicit flag set by default.


Where we have the flexability and it does not sacrafice
correctness or the spirit of VHDL, we should give people
the ability to adopt their own methodology. The great
thing about this being a package is that if you like
a methodology that uses only numeric_std, then don't
include the other package and life is good.


Cheers,
Jim
P.S.
Note there are _no_ plans to create a numeric_signed.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Mike Treseler]

Nicolas Matringe wrote:

On the standard horizon, there will be a numeric_unsigned
package from IEEE, however, there will not be a
numeric_signed package.

Maybe I am not an advanced user enough but I can't see what's missing in
numeric_std that would need the addition of a new package.

I agree with you, but many vhdl designers
prefer to do math directly with type std_logic_vector.

-- Mike Treseler

 

[Nicolas Matringe]

Mike Treseler a écrit:

Nicolas Matringe wrote:

Maybe I am not an advanced user enough but I can't see what's missing
in numeric_std that would need the addition of a new package.

I agree with you, but many vhdl designers
prefer to do math directly with type std_logic_vector.

*sigh*
Anyway, as Jim Lewis said, if you don't like it don't use it.


--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/

 

[rickman]

Paul Uiterlinden wrote:

....snip...
With ieee.std_logic_(un)signed, you cannot mix signed and unsigned
operations in one design unit using those packages.

With ieee.numeric_std you can, because you always have to use the types
signed or unsigned for arithmetic operation on vectors.

When using an arithmetic operation on a std_logic_vector, some
conversions back and forth must be used, making the code quite lengthy:

VARIABLE a: std_logic_vector(7 DOWNTO 0);

a := std_logic_vector(unsigned(a) + 1);

That's why I think people are asking for numeric_unsigned, making it
possible to write "a := a + 1;" again.

Of course, changing the type of "a" to unsigned(7 DOWNTO 0) would
accomplish the same, but you will need a conversion again when assigning
"a" to a std_logic_vector.

I am not sure this will be good in the end. I guess since all
arithmetic on slv will be unsigned, it can be clear. But the only real
indicator of what is going on is the line using the numeric_unsigned
library. Maybe it is just me, but it seems like the current approach is
much more clear.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Jim Lewis]

Narendran Kumaraguru Nathan wrote:

The ieee packages "std_logic_arith", "std_logic_unsigned" &
"std_logic_signed" have overloaded the "+" operator.

Minor clarification:
Packages "std_logic_arith", "std_logic_unsigned" &
"std_logic_signed" are from Synopsys and are distributed
as free-ware. Hence they are well supported by many tools.
The fact that they were put in the ieee library is
contentious and some feel they should be removed - however -
many others agree it is contentious, they do not
see any value in breaking old code.


Package numeric_std is the recommended IEEE package
for new designs. It also overloads addition to allow
use of integers with unsigned/signed.

On the standard horizon, there will be a numeric_unsigned
package from IEEE, however, there will not be a
numeric_signed package.

Like Narendran stated in his follow-up email, optimization of
the addition of an unsigned/signed with a constant integer
value (or a constant value of type unsigned/signed) will be
appropriately handled by synthesis tools.

Regards,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[rickman]

Julian wrote:

Hi NG.

This is more a digital design related question, hope you have an idea.
Is there a fast way of adding one (1) to any number? Is there another way
than implementing an actual complete adder structure? Could this in some way
be reduced as we now have a fixed constant to add?

There is no magic reduction that adding a constant will provide. But in
an FPGA the circuit is a bit simpler than adding two variable numbers.
Adding one only requires a series of half adders vs. a chain of full
adders. You still need a LUT for each bit, but you have some free
inputs to the LUT that can be used to add other functions such as a mux,
load or clear control.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX