hex notation

A

Andreas Hölscher

Guest
Hi,
I have code like this:

cs_reg <= '1' when Adr = conv_std_logic_vector(21,8) else '0';

To get my code more readable I want to use hexadecimal numbers for the
address. I tried to replace the 21 with 0x15, 15h, x"15" but nothing works.

Any hint?

Thanks,
Andreas
 
Andreas Hölscher a écrit:
Hi,
I have code like this:

cs_reg <= '1' when Adr = conv_std_logic_vector(21,8) else '0';

To get my code more readable I want to use hexadecimal numbers for the
address. I tried to replace the 21 with 0x15, 15h, x"15" but nothing works.

Any hint?

Thanks,
Andreas
The problem is that x"15" can be of different types (is it
std_logic_vector, bit_vector, unsigned, signed?) so the tools don't know
which '=' function to use.
Your code only works if you don't use any numeric or arithmetic package,
otherwise you'll have to type cast your litteral constant:
... when Adr = std_logic_vector(x"15") ...

Nicolas
 
I disagree.
As long as one of the objects in the comparison
is a signal/variable/constant, the comparison will
not be ambiguous.

The only issue here is making sure you turn on
the VHDL-93 mode. In ModelSim it is in the upper
left corner of the compile option menu. There is
no reason not to turn this on for all designs.

So, the following will work:
use ieee.numeric_std.all ;
signal Addr : unsigned (7 downto 0) ;

cs_reg <= '1' when Addr = X"15" else '0' ;


Also works when Addr is std_logic_vector, but
be careful. If you are not using package
std_logic_unsigned, and you do a comparison with
std_logic_vector, it is a dictionary sort rather
than a numeric sort. If all values are either '1'
or '0' and the vectors are the same length, a
dictionary sort is the same as a numeric sort,
otherwise, be careful.

Cheers,
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nicolas Matringe wrote:

Andreas Hölscher a écrit:

Hi,
I have code like this:

cs_reg <= '1' when Adr = conv_std_logic_vector(21,8) else '0';

To get my code more readable I want to use hexadecimal numbers for the
address. I tried to replace the 21 with 0x15, 15h, x"15" but nothing
works.

Any hint?

Thanks,
Andreas


The problem is that x"15" can be of different types (is it
std_logic_vector, bit_vector, unsigned, signed?) so the tools don't know
which '=' function to use.
Your code only works if you don't use any numeric or arithmetic package,
otherwise you'll have to type cast your litteral constant:
... when Adr = std_logic_vector(x"15") ...

Nicolas
 
Jim Lewis a écrit:
I disagree.
As long as one of the objects in the comparison
is a signal/variable/constant, the comparison will
not be ambiguous.
You're right, I apologize.
I recall having had some problem like that though... (litteral constants
possibly being of different types)

Nicolas
 
In package std_logic_arith comparisions of signed and
unsigned with a string literal are ambiguous:

use ieee.std_logic_arith.all ;
signal A : unsigned(3 downto 0) ;

if A = "1111" then ...


It is ambiguous because std_logic_arith overloads
"=" as follows:
1 function "=" (l: unsigned; r : unsigned) return boolean ;
2 function "=" (l: signed; r : signed) return boolean ;
3 function "=" (l: unsigned; r : signed) return boolean ;
4 function "=" (l: signed; r : unsigned) return boolean ;

It is the last two that are problematic. In the previous
example, 1 and 3 are potential solutions and hence it is
ambiguous. In a way, they ask, is it 15 (unsigned) or is
it -1 (signed).

We don't see this as much since people have switched
(or are being encouraged to switch) to numeric_std.
Numeric_std leaves out the last two functions and, hence,
no problem.

BTW, since signed and unsigned are numerics, there was another
easy solution in this case - use an integer:

if A = 15 then ...


Both packages provide this overloading.

Cheers,
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Nicolas Matringe wrote:

Jim Lewis a écrit:

I disagree.
As long as one of the objects in the comparison
is a signal/variable/constant, the comparison will
not be ambiguous.


You're right, I apologize.
I recall having had some problem like that though... (litteral constants
possibly being of different types)

Nicolas
 
Try & use ieee.numeric_std & not the signed & unsigned packages (which came
from Synopsys IIRC).
I know it can be a bit more convoluted when all signals/ports are declared
as SLVs, but I think it wins in the end.
Niv.

"Jim Lewis" <Jim@SynthWorks.com> wrote in message
news:vth778g5kr5h03@corp.supernews.com...
In package std_logic_arith comparisions of signed and
unsigned with a string literal are ambiguous:

use ieee.std_logic_arith.all ;
signal A : unsigned(3 downto 0) ;

if A = "1111" then ...


It is ambiguous because std_logic_arith overloads
"=" as follows:
1 function "=" (l: unsigned; r : unsigned) return boolean ;
2 function "=" (l: signed; r : signed) return boolean ;
3 function "=" (l: unsigned; r : signed) return boolean ;
4 function "=" (l: signed; r : unsigned) return boolean ;

It is the last two that are problematic. In the previous
example, 1 and 3 are potential solutions and hence it is
ambiguous. In a way, they ask, is it 15 (unsigned) or is
it -1 (signed).

We don't see this as much since people have switched
(or are being encouraged to switch) to numeric_std.
Numeric_std leaves out the last two functions and, hence,
no problem.

BTW, since signed and unsigned are numerics, there was another
easy solution in this case - use an integer:

if A = 15 then ...


Both packages provide this overloading.

Cheers,
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Nicolas Matringe wrote:

Jim Lewis a écrit:

I disagree.
As long as one of the objects in the comparison
is a signal/variable/constant, the comparison will
not be ambiguous.


You're right, I apologize.
I recall having had some problem like that though... (litteral constants
possibly being of different types)

Nicolas
 
Hey Niv,
?????
If you get off you hot button and read the entire
post you would learn that I recommended numeric_std.
The thing that you went off on was simply demonstrating
why std_logic_arith is bad. So at least wrt usage of
std_logic_arith we agree.

Note I never did mention usage of std_logic_unsigned.
However, since you did, I do use std_logic_unsigned
and I plan to keep using it until either 1076.3
creates a numeric_std_unsigned or 1164 adds unsigned
math for std_logic_vector.

For std_logic_unsigned, I think there are several potential
valid methodologies:
1) Don't use it. Always use types unsigned and signed for math.
2) Allow usage of std_logic_vector, for doing unsigned math
in testbenches. For example algorithmically incrementing
an address in a testbench.
3) 2 + Allow usage of std_logic_vector for counters.
4) Permit std_logic_vector for any unsigned math.

So I am guessing you always follow 1. This is conservative.
Realistically life can be painful in testbenches if
you are not doing 2 above. On some projects I do 3,
on some I don't. I never do 4.

I realize usage of std_logic_unsigned is a religous topic.
Note, I recommend people never use std_logic_signed.

Cheers,
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 

Welcome to EDABoard.com

Sponsor

Back
Top