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

On May 31, 3:43 pm, Jonathan Bromley <jonathan.brom...@[EMAIL PROTECTED]
>
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