Signed, Unsigned syntax issues. Please help, I'm stumped

I'm still a little new to Xilinx so I'm working through some syntax
issues. I'm working with ISE 10.1



After running "check syntax", I get the following errors.



ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 92. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED
ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 114. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED
ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 145. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED



here are the lines being referred to:



Line 92: if setup_sample = "1111111" then

Line 114: curval <= countupstuff when setup_sample = "1111110";

Line 145: elsif apnea_count = "1101001101010101100100000" then



The errors seem to be implying that I haven't specified these signals
as either signed or unsigned. But the following part of my code does
specify all these signals as unsigned



(these are lines 39 through 47)


architecture Behavioral of SS08 is

signal countupstuff, curval, sample, count_1khz : unsigned (15 downto
0);
signal apnea_reset, alarm_out, clock1k, clock1k_int, inc_apnea_count,
inc_not_apnea, clock32x, clock32x_int, settozero : std_logic;
signal apnea_count, not_apnea : unsigned (24 downto 0);
signal count_1Mhz : unsigned (4 downto 0);
signal setup_sample : unsigned (6 downto 0);

begin


Interesting note, I was previously running this code on ISE 9.1 and it
didn't have a problem with it.


Can any one shed some light on why I'm getting these errors? It would
be very much appreciated. Let me know if you need any more
information.



Thanks,



Jeff

nitrogenocide@gmail.com

<> wrote in message
news:62d67656-1b11-4741-895b-...
> After running "check syntax", I get the following errors.
>
> ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 92. = has two
> or more possible definitions in this scope. For example, parameter 2
> (string value) can be: SIGNED or UNSIGNED
> ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 114. = has two
> or more possible definitions in this scope. For example, parameter 2
> (string value) can be: SIGNED or UNSIGNED
> ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 145. = has two
> or more possible definitions in this scope. For example, parameter 2
> (string value) can be: SIGNED or UNSIGNED
>
>
> here are the lines being referred to:
>
> Line 92: if setup_sample = "1111111" then
>
> Line 114: curval <= countupstuff when setup_sample = "1111110";
>
> Line 145: elsif apnea_count = "1101001101010101100100000" then
>
>
> The errors seem to be implying that I haven't specified these signals
> as either signed or unsigned. But the following part of my code does
> specify all these signals as unsigned

But the thing you're comparing them to (i.e. "1111111" and "1111110" are
ambiguous). You need to tell it if it is signed or unsigned like this

unsigned'("1111110")

Note the tick mark.

KJ
>
>
>
> (these are lines 39 through 47)
>
>
> architecture Behavioral of SS08 is
>
> signal countupstuff, curval, sample, count_1khz : unsigned (15 downto
> 0);
> signal apnea_reset, alarm_out, clock1k, clock1k_int, inc_apnea_count,
> inc_not_apnea, clock32x, clock32x_int, settozero : std_logic;
> signal apnea_count, not_apnea : unsigned (24 downto 0);
> signal count_1Mhz : unsigned (4 downto 0);
> signal setup_sample : unsigned (6 downto 0);
>
> begin
>
>
> Interesting note, I was previously running this code on ISE 9.1 and it
> didn't have a problem with it.
>
>
> Can any one shed some light on why I'm getting these errors? It would
> be very much appreciated. Let me know if you need any more
> information.
>
>
>
> Thanks,
>
>
>
> Jeff

KJ

wrote:

> ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 145. = has two
> or more possible definitions in this scope. For example, parameter 2
> (string value) can be: SIGNED or UNSIGNED

> Line 145: elsif apnea_count = "1101001101010101100100000" then

> The errors seem to be implying that I haven't specified these signals
> as either signed or unsigned. But the following part of my code does
> specify all these signals as unsigned

Declare the constants also:

> architecture Behavioral of SS08 is
>
subtype cnt25_t is unsigned(24 downto 0);
signal apnea_count, not_apnea : cnt25_t;
constant cnt25_c :: cnt25_t := "1101001101010101100100000";
....
etc.

Put this at the top:

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


-- Mike Treseler

Mike Treseler

Mike Treseler wrote:

> constant cnt25_c :: cnt25_t := "1101001101010101100100000";
constant cnt25_c : cnt25_t := "1101001101010101100100000";

Mike Treseler

"Jonathan Bromley" <> wrote in message
news:...
> On Sat, 31 May 2008 11:58:04 -0700 (PDT), nitrogenocide wrote:
>
>
> Intriguingly, this exact issue came up here only a couple
> of days ago.
>

A regular conspiracy going on

> It's almost certainly because you are accepting the goofy
> Xilinx default VHDL code template which has, inter alia,
>
> USE IEEE.STD_LOGIC_ARITH.all;
>
> No-one can explain why Xilinx (and others too) continue
> to recommend in this way the use of a package that was
> superseded by the better, more complete, properly
> standardised IEEE.NUMERIC_STD over a decade ago.
>

That would bring them up to the 90s now wouldn't it....only 15 or so years
behind the standards.

>
> The less satisfactory fix (hack) is to make the type
> of your constants explicit:
>
> if setup_sample = UNSIGNED'("1111111") then
>
> This is known as a "type qualification"; note the
> apostrophe between the type name and the opening
> parenthesis.
>

If for some reason you reeeeeally didn't want to properly define a constant
to do the job, I think using the type qualifier is better (not a hack)
since, even if the compiler has no ambiguity, the reader may and having the
type qualifier makes it explicit to the reader as to the intended
type...documentation comes in all forms.

Kevin Jennings

KJ

On May 31, 4:53 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Jonathan Bromley" <jonathan.brom...@MYCOMPANY.com> wrote in message
>
> news:...
>
> > On Sat, 31 May 2008 11:58:04 -0700 (PDT), nitrogenocide wrote:
>
> > Intriguingly, this exact issue came up here only a couple
> > of days ago.
>
> A regular conspiracy going on
>
> > It's almost certainly because you are accepting the goofy
> > Xilinx default VHDL code template which has, inter alia,
>
> > USE IEEE.STD_LOGIC_ARITH.all;
>
> > No-one can explain why Xilinx (and others too) continue
> > to recommend in this way the use of a package that was
> > superseded by the better, more complete, properly
> > standardised IEEE.NUMERIC_STD over a decade ago.
>
> That would bring them up to the 90s now wouldn't it....only 15 or so years
> behind the standards.

I opened up a Web Case about this. Let's see if they give a ****.

Oh, yeah, in that same Web Case, I suggested that their templates use:

if rising_edge(clk) then

instead of

if (clk'event and clk = '1') then

It's almost halfway through 2008 ...

=-a

Andy Peters

On May 31, 3:43 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Sat, 31 May 2008 11:58:04 -0700 (PDT), nitrogenocide wrote:
> >After running "check syntax", I get the following errors.
> >ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 92. = has two
> >or more possible definitions in this scope. For example, parameter 2
> >(string value) can be: SIGNED or UNSIGNED
> [etc]
> >Line 92: if setup_sample = "1111111" then
>
> [etc]
>
> >The errors seem to be implying that I haven't specified these signals
> >as either signed or unsigned. But the following part of my code does
> >specify all these signals as unsigned
>
> Intriguingly, this exact issue came up here only a couple
> of days ago.
>
> It's almost certainly because you are accepting the goofy
> Xilinx default VHDL code template which has, inter alia,
>
> USE IEEE.STD_LOGIC_ARITH.all;
>
> No-one can explain why Xilinx (and others too) continue
> to recommend in this way the use of a package that was
> superseded by the better, more complete, properly
> standardised IEEE.NUMERIC_STD over a decade ago.
>
> The specific issue is that STD_LOGIC_ARITH provides
> definitions of the "=" operator for all the following
> combinations of types:
>
> UNSIGNED = UNSIGNED
> UNSIGNED = SIGNED
> SIGNED = UNSIGNED
> SIGNED = SIGNED
>
> If the things on the opposite sides of the "=" are
> simple variables or signals, that's fine - but if they
> are expressions, or literals like your "111111", there
> is a type ambiguity because the literal might be either
> SIGNED or UNSIGNED, and VHDL can't work out which it is.
>
> The preferred fix is to replace STD_LOGIC_ARITH with
> NUMERIC_STD. This will fix the type ambiguity issue, but
> it may give you a few other compile errors because the
> conversion functions' names have changed: conv_integer()
> is now to_integer, and conv_unsigned() is now called
> to_unsigned(). Obviously, those will be rather easy
> to deal with. This is by far the most satisfactory
> solution. NUMERIC_STD defines equality for
> UNSIGNED=UNSIGNED and for SIGNED=SIGNED, but not
> for combinations of the two - so, in your comparison,
> there is only one possible interpretation of the
> constant and VHDL will get it right automatically.

I can't sat that Numemric_std is a panacea. VHDL is still a tough
language to master in terms of the strong typing. It is hard to even
figure out what the true nature of the problem is in many cases. Here
is one that I am currently dealing with. I just changed a number of
slvs to unsigned and now I get this error.

if (CTPCurCmd(VER_RNG) = '1') and (DataOutReg /= CTPCurCmd(DAT_RNG))
then

---No matching overload for "/="---

DataOutReg is slv and CTPCurCmd is unsigned. I thought that the two
types were "closely related" which means I don't have to use
conversions to intermix them. I also get errors when trying to
concatenate slv with unsigned. What exactly is wrong with either of
these? I guess it doesn't know what type to make the result of a
concatenation, but the equality comparison shouldn't have that
problem.

Rick

rickman

rickman wrote:

> ---No matching overload for "/="---
>
> DataOutReg is slv and CTPCurCmd is unsigned. I thought that the two
> types were "closely related" which means I don't have to use
> conversions to intermix them.

No, closely related means I can use
a cast instead of a conversion as in:

unsigned(DataOutReg) /= CTPCurCmd(DAT_RNG)

Let's look up the "/=" functions available
in the numeric_std source here:

http://www.cs.umbc.edu/help/VHDL/pac...umeric_std.vhd

function "/=" (L,R: UNSIGNED ) return BOOLEAN;
function "/=" ( L,R: SIGNED) return BOOLEAN;
function "/=" ( L: NATURAL; R: UNSIGNED) return BOOLEAN;
function "/=" ( L: INTEGER; R: SIGNED) return BOOLEAN;
function "/=" ( L: UNSIGNED; R: NATURAL) return BOOLEAN;
function "/=" ( L: SIGNED; R: INTEGER) return BOOLEAN;

For your example, a cast is needed to match the first signature.

-- Mike Treseler

Mike Treseler

On Jun 9, 1:06 pm, rickman <gnu...@gmail.com> wrote:
> On May 31, 3:43 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
> wrote:
>
>
>
> > On Sat, 31 May 2008 11:58:04 -0700 (PDT), nitrogenocide wrote:
> > >After running "check syntax", I get the following errors.
> > >ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 92. = has two
> > >or more possible definitions in this scope. For example, parameter 2
> > >(string value) can be: SIGNED or UNSIGNED
> > [etc]
> > >Line 92: if setup_sample = "1111111" then
>
> > [etc]
>
> > >The errors seem to be implying that I haven't specified these signals
> > >as either signed or unsigned. But the following part of my code does
> > >specify all these signals as unsigned
>
> > Intriguingly, this exact issue came up here only a couple
> > of days ago.
>
> > It's almost certainly because you are accepting the goofy
> > Xilinx default VHDL code template which has, inter alia,
>
> > USE IEEE.STD_LOGIC_ARITH.all;
>
> > No-one can explain why Xilinx (and others too) continue
> > to recommend in this way the use of a package that was
> > superseded by the better, more complete, properly
> > standardised IEEE.NUMERIC_STD over a decade ago.
>
> > The specific issue is that STD_LOGIC_ARITH provides
> > definitions of the "=" operator for all the following
> > combinations of types:
>
> > UNSIGNED = UNSIGNED
> > UNSIGNED = SIGNED
> > SIGNED = UNSIGNED
> > SIGNED = SIGNED
>
> > If the things on the opposite sides of the "=" are
> > simple variables or signals, that's fine - but if they
> > are expressions, or literals like your "111111", there
> > is a type ambiguity because the literal might be either
> > SIGNED or UNSIGNED, and VHDL can't work out which it is.
>
> > The preferred fix is to replace STD_LOGIC_ARITH with
> > NUMERIC_STD. This will fix the type ambiguity issue, but
> > it may give you a few other compile errors because the
> > conversion functions' names have changed: conv_integer()
> > is now to_integer, and conv_unsigned() is now called
> > to_unsigned(). Obviously, those will be rather easy
> > to deal with. This is by far the most satisfactory
> > solution. NUMERIC_STD defines equality for
> > UNSIGNED=UNSIGNED and for SIGNED=SIGNED, but not
> > for combinations of the two - so, in your comparison,
> > there is only one possible interpretation of the
> > constant and VHDL will get it right automatically.
>
> I can't sat that Numemric_std is a panacea. VHDL is still a tough
> language to master in terms of the strong typing. It is hard to even
> figure out what the true nature of the problem is in many cases. Here
> is one that I am currently dealing with. I just changed a number of
> slvs to unsigned and now I get this error.
>
> if (CTPCurCmd(VER_RNG) = '1') and (DataOutReg /= CTPCurCmd(DAT_RNG))
> then
>
> ---No matching overload for "/="---
>
> DataOutReg is slv and CTPCurCmd is unsigned. I thought that the two
> types were "closely related" which means I don't have to use
> conversions to intermix them. I also get errors when trying to
> concatenate slv with unsigned. What exactly is wrong with either of
> these? I guess it doesn't know what type to make the result of a
> concatenation, but the equality comparison shouldn't have that
> problem.
>
> Rick

"closely related" types only means you don't have to write a
conversion function between them, but you still have to use one. It is
invoked as the name of the type you are converting to.

if unsigned(my_slf) < my_unsigned then...

Andy

Andy

On Jun 9, 2:28 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
> rickman wrote:
> > ---No matching overload for "/="---
>
> > DataOutReg is slv and CTPCurCmd is unsigned. I thought that the two
> > types were "closely related" which means I don't have to use
> > conversions to intermix them.
>
> No, closely related means I can use
> a cast instead of a conversion as in:
>
> unsigned(DataOutReg) /= CTPCurCmd(DAT_RNG)
>
> Let's look up the "/=" functions available
> in the numeric_std source here:
>
> http://www.cs.umbc.edu/help/VHDL/pac...umeric_std.vhd
>
> function "/=" (L,R: UNSIGNED ) return BOOLEAN;
> function "/=" ( L,R: SIGNED) return BOOLEAN;
> function "/=" ( L: NATURAL; R: UNSIGNED) return BOOLEAN;
> function "/=" ( L: INTEGER; R: SIGNED) return BOOLEAN;
> function "/=" ( L: UNSIGNED; R: NATURAL) return BOOLEAN;
> function "/=" ( L: SIGNED; R: INTEGER) return BOOLEAN;
>
> For your example, a cast is needed to match the first signature.
>
> -- Mike Treseler

I have seen to_unsigned(), unsigned() and unsigned'. I understand
that the first to are conversion and type casting respectively. What
is the third called? I expect this is only for use where a literal or
expression can be interpreted more than one way and explains to the
tool what is intended, right?

I read back a bit and see that it is a "type qualification". I think
I got all that now. So even when types are closely related, you still
have to explicitly tell the tool to change the interpretation.

I think I wish I had started with Verilog instead of VHDL. At least
now if I start coding in Verilog, it will be an informed decision.
The little Verilog I have coded was very easy to do and I did it with
*no* additional training. I just picked up a little from a book and
the rest came pretty easy.

Does Verilog support user libraries in a similar manner to VHDL?

Rick

rickman