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

On Jun 9, 1:06 pm, rickman <gnu...@[EMAIL PROTECTED]
> wrote:
> 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

"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