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

Discussion in 'VHDL' started by nitrogenocide@gmail.com, May 31, 2008.

  1. Guest

    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
     
    , May 31, 2008
    #1
    1. Advertising

  2. KJ Guest

    <> wrote in message
    news:...
    > 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, May 31, 2008
    #2
    1. Advertising

  3. 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, May 31, 2008
    #3
  4. Re: Signed, Unsigned syntax issues. --typo

    Mike Treseler wrote:

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

    constant cnt25_c : cnt25_t := "1101001101010101100100000";
     
    Mike Treseler, May 31, 2008
    #4
  5. KJ Guest

    "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, Jun 1, 2008
    #5
  6. Andy Peters Guest

    On May 31, 4:53 pm, "KJ" <> wrote:
    > "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.


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

    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, Jun 2, 2008
    #6
  7. rickman Guest

    On May 31, 3:43 pm, Jonathan Bromley <>
    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, Jun 9, 2008
    #7
  8. 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/packages/numeric_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, Jun 9, 2008
    #8
  9. Andy Guest

    On Jun 9, 1:06 pm, rickman <> wrote:
    > On May 31, 3:43 pm, Jonathan Bromley <>
    > 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, Jun 9, 2008
    #9
  10. rickman Guest

    On Jun 9, 2:28 pm, Mike Treseler <> 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/packages/numeric_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, Jun 10, 2008
    #10
  11. rickman wrote:

    > 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?


    That's it.

    > 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.


    Yes, but keep in mind that I don't need *any* of these
    functions if I declare my variable and constant
    vectors correctly in the first place.
    Here's an example of how I do this using subtypes:
    http://mysite.verizon.net/miketreseler/sync_template.vhd

    And don't leave home without your cheat sheets:
    http://www.vhdl.org/rassp/vhdl/guidelines/vhdlqrc.pdf
    http://www.vhdl.org/rassp/vhdl/guidelines/1164qrc.pdf

    > 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.


    I expect that it would take longer
    to learn verilog well than to learn
    the vhdl numeric libraries.
    If Andy were here, he would remind you
    that integer ranges also work fine for synthesis
    and require no libraries.

    > 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.


    It's a rose for easy projects, but just thorns for debugging
    complicated modules with signed and unsigned math.

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


    No.


    -- Mike Treseler
     
    Mike Treseler, Jun 10, 2008
    #11
  12. Andy Guest

    On Jun 9, 6:55 pm, rickman <> wrote:
    > On Jun 9, 2:28 pm, Mike Treseler <> 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/packages/numeric_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


    A long time ago there was a live design/coding contest between being
    Verilog and VHDL to code a small module that had a few strange
    requirements, but was otherwise pretty straight forward. Verilog
    trounced VHDL. But if you stopped there, and assumed Verilog was
    better than VHDL for most digital design, you missed the point.
    Anything that can be converted from spec to synthesized gates in an
    hour or two will almost necessarily be the easiest/quickest to design
    in the simplest, most constrained language capable of doing that
    simple job, namely verilog. Is that the basis upon which you want to
    choose your development language?

    To keep Mike an honest man: VHDL synthesis tools support arithmetic
    for integers without additional libraries. However, bit-wise logic
    operations on integers are not supported without custom libraries, and
    standard ranges for integers limit data widths to 31 bits unsigned and
    32 bit signed.

    One more point: just try to design a fixed or floating point
    arithmetic design with verilog!

    Andy
     
    Andy, Jun 10, 2008
    #12
  13. rickman Guest

    On Jun 10, 5:59 pm, Andy <> wrote:
    > On Jun 9, 6:55 pm, rickman <> wrote:
    >
    >
    >
    > > On Jun 9, 2:28 pm, Mike Treseler <> 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/packages/numeric_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

    >
    > A long time ago there was a live design/coding contest between being
    > Verilog and VHDL to code a small module that had a few strange
    > requirements, but was otherwise pretty straight forward. Verilog
    > trounced VHDL. But if you stopped there, and assumed Verilog was
    > better than VHDL for most digital design, you missed the point.
    > Anything that can be converted from spec to synthesized gates in an
    > hour or two will almost necessarily be the easiest/quickest to design
    > in the simplest, most constrained language capable of doing that
    > simple job, namely verilog. Is that the basis upon which you want to
    > choose your development language?


    I recall that competition and I seem to recall that it was *very*
    inconclusive. Although the Verilog teams seemed to be further along,
    not one team produced working code in the time alloted. I guess this
    could be a different contest though.


    > To keep Mike an honest man: VHDL synthesis tools support arithmetic
    > for integers without additional libraries. However, bit-wise logic
    > operations on integers are not supported without custom libraries, and
    > standard ranges for integers limit data widths to 31 bits unsigned and
    > 32 bit signed.


    I don't care if libraries are required for various features. I was
    asking about support for user libraries in Verilog. I believe the
    answer was no. Is that still valid?


    > One more point: just try to design a fixed or floating point
    > arithmetic design with verilog!


    Is that a point? What was the point? Are you trying to say that
    users don't design arithmetic circuits in Verilog??? I am pretty sure
    that the limited work I have done in Verilog has included arithmetic.
    I must be missing your point.


    BTW, here is one of the reasons I am getting tried of using VHDL. I
    have coded FPGAs in VHDL off and on for some 10 years. Every time I
    start a new design (sometimes as long as 18 months since the last one)
    I have to pick up all of my books again to remember the details and to
    read my notes on the various shortcuts to efficient use. I typically
    find that the shortcuts are not very short and look for new ones. The
    notation is just so verbose for simple things. Here is an example.

    CTPBitCnt is an unsigned.

    What I mean...
    CTPBitCnt <= 1;

    What I have to write...
    CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);

    Doesn't that seem a bit wordy? I guess this example goes back to the
    inability to overload the assignment operator which someone has
    indicated may be changed in the next revision of the language.

    Rick
     
    rickman, Jun 11, 2008
    #13
  14. KJ Guest

    On Jun 11, 11:52 am, rickman <> wrote:
    > On Jun 10, 5:59 pm, Andy <> wrote:
    > notation is just so verbose for simple things.  Here is an example.
    >
    > CTPBitCnt is an unsigned.
    >
    > What I mean...
    >   CTPBitCnt <= 1;
    >
    > What I have to write...
    >   CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
    >
    > Doesn't that seem a bit wordy?  I guess this example goes back to the
    > inability to overload the assignment operator which someone has
    > indicated may be changed in the next revision of the language.
    >


    I agree it is too wordy and also prone to error (like if you get
    sloppy and type "8" instead of "CTPBitCnt'length" and then later
    change the range of "CTPBitCnt")

    If this were legal...

    CTPBitCnt <= to_unsigned(1)

    I wouldn't think it to be too wordy since it is specifying a type
    conversion and having explicit type conversions is preferrable (to
    me).

    In the meantime one could create a procedure like the following and
    put it into a package of commonly used VHDL shortcuts...

    procedure set(L: out unsigned; R: in integer) is
    begin
    L := to_unsigned(R, L'length);
    end procedure set;

    which could then be used like this...
    set(Test_Set, 1);

    But then you'd need to overload it so you could pass signals instead
    of variables...and hope that the name 'set' (or whatever you come up
    with) sticks in your mind as to be clear about what it's purpose
    is....sigh

    Kevin Jennings
     
    KJ, Jun 11, 2008
    #14
  15. rickman wrote:

    > What I mean...
    > CTPBitCnt <= 1;
    >
    > What I have to write...
    > CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
    >
    > Doesn't that seem a bit wordy?


    Yes. Declare CTPBitCnt unsigned instead of std_logic_vector.

    CTPBitCnt <= x"0001";

    -- Mike Treseler
     
    Mike Treseler, Jun 11, 2008
    #15
  16. KJ Guest

    On Jun 11, 2:14 pm, Mike Treseler <> wrote:
    > rickman wrote:
    > > What I mean...
    > >   CTPBitCnt <= 1;

    >
    > > What I have to write...
    > >   CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);

    >
    > > Doesn't that seem a bit wordy?

    >
    > Yes. Declare CTPBitCnt unsigned instead of std_logic_vector.
    >


    He did declare it as unsigned.

    >     CTPBitCnt <=  x"0001";
    >


    Doesn't work though if the length of CTPBitCnt is anything other than
    a multiple of 4 bits (i.e. CTPBitCnt: unsigned(12 downto 0));

    KJ
     
    KJ, Jun 11, 2008
    #16
  17. rickman Guest

    On Jun 11, 2:41 pm, KJ <> wrote:
    > On Jun 11, 2:14 pm, Mike Treseler <> wrote:
    >
    > > rickman wrote:
    > > > What I mean...
    > > > CTPBitCnt <= 1;

    >
    > > > What I have to write...
    > > > CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);

    >
    > > > Doesn't that seem a bit wordy?

    >
    > > Yes. Declare CTPBitCnt unsigned instead of std_logic_vector.

    >
    > He did declare it as unsigned.
    >
    > > CTPBitCnt <= x"0001";


    This works with signed, unsigned and SLV!

    > Doesn't work though if the length of CTPBitCnt is anything other than
    > a multiple of 4 bits (i.e. CTPBitCnt: unsigned(12 downto 0));


    Worse, I have to hard code the width of the signal which I try to
    avoid. That is why I want to assign it a value from an integer and
    not specify every bit in the vector. For example, all of my address
    values are currently 8 bits. My customer may decide to change the
    protocol to use 6 bits since that is plenty enough. I would hate to
    have to go through the entire body of code changing 8 bit constants to
    6 bits.

    VHDL just makes life hard in some ways.

    Rick
     
    rickman, Jun 12, 2008
    #17
  18. KJ Guest

    On Jun 11, 12:17 pm, KJ <> wrote:
    > On Jun 11, 11:52 am, rickman <> wrote:


    >
    > In the meantime one could create a procedure like the following and
    > put it into a package of commonly used VHDL shortcuts...
    >
    > procedure set(L: out unsigned; R: in integer) is
    > begin
    >   L := to_unsigned(R, L'length);
    > end procedure set;
    >
    > which could then be used like this...
    > set(Test_Set, 1);
    >
    > But then you'd need to overload it so you could pass signals instead
    > of variables...and hope that the name 'set' (or whatever you come up
    > with) sticks in your mind as to be clear about what it's purpose
    > is....sigh
    >


    Slight correction to the previous. You can't overload the 'set'
    function to have one that works with signals and another that works
    with variables, you'd need to have two distinctly named functions
    (i.e. 'setsig' and 'setvar')...all for the lack of being able to
    overload the assignment operators....

    KJ
     
    KJ, Jun 12, 2008
    #18
  19. rickman wrote:

    > This works with signed, unsigned and SLV!


    Yes sorry, I didn't read your post carefully.

    >> Doesn't work though if the length of CTPBitCnt is anything other than
    >> a multiple of 4 bits (i.e. CTPBitCnt: unsigned(12 downto 0));


    That is annoying,
    and that is why I declare a subtype for vector constants:

    subtype vec_t is unsigned(vec_len-1 downto 0);

    constant vec_zero_c : vec_t := (others => '0');
    constant vec_one_c : vec_t := vec_init_c + 1;
    constant vec_load_c : vec_t := vec_init_c + 42;

    CTPBitCnt <= vec_one_c;


    > VHDL just makes life hard in some ways.


    And easy in other ways ;)

    -- Mike Treseler
     
    Mike Treseler, Jun 12, 2008
    #19
  20. KJ Guest

    "Jim Lewis" <> wrote in message
    news:...
    > rickman
    >> Here is an example.
    >>
    >> CTPBitCnt is an unsigned.
    >>
    >> What I mean...
    >> CTPBitCnt <= 1;
    >>
    >> What I have to write...
    >> CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
    >>


    >
    > Jonathan just submitted a language feature request WRT to overloading
    > assignment, however, the standard is already at the balloting point so
    > it will not make the 2008 revision.
    >
    > What has been added is a decimal notation for bit string literals
    > and a sizing indication.
    >
    > signal CTPBitCnt : unsigned (14 downto 0) ; -- 15 bits
    > . . .
    > -- Representing 1 as a 15 bit object in either hex or decimal
    >
    > CTPBitCnt <= 15D"1" ; -- Decimal notation
    > CTPBitCnt <= 15X"1" ; -- Hex notation
    >


    The type of syntax only a mother could love. Let's compare the approaches
    A: CTPBitCnt <= 1;
    B: CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
    C: CTPBitCnt <= to_unsigned(1);
    D: set(CTPBitCnt, "<=", 1)
    E: CTPBitCnt <= CTPBitCnt'lengthD"1" ; or CTPBitCnt <= CTPBitCnt'lengthX"1"
    ??
    F: CTPBitCnt <= 8D"1" ; or CTPBitCnt <= 8X"1"

    'A' is illegal, but represents what is intended. Violates strong type
    checking which is a 'good' thing about VHDL (in my opinion).

    'B' has been valid since VHDL'93 but is overly wordy and prone to error if
    you inadvertnatly take the 'length of something other than the left side of
    the statement. Has an issue that you would need separately names procedures
    if the thing being assigned to is a signal or a variable. Jim, is there
    anything on the table about being able to overload procedures when
    parameters differ by class so that a single name could be used? If not,
    maybe I'll submit it for consideration.

    'C' is illegal, but represents what is intended and conforms nicely with the
    strong type checking of VHDL. Requires acceptance of overloading of the
    "<=" and ":=" operators as Jonathon has proposed.

    'D' is valid VHDL where 'set' is a procedure that implements the syntax of
    'B'. No chance for the possible user error mentioned above for 'B'. The
    second parameter "<=" is not used in the procedure it is there simply to aid
    the user of the procedure.

    'E' may be valid VHDL'2008 (not sure if the bit width specification needs to
    be a hard coded can be replaced with something that will be maintainable if
    'CTPBitCnt' is subject to size changes ....ummm, kind of at a loss to say
    anything that I like about that syntax.
    'F' is valid VHDL'2008 but again can't say what there may be to like about
    it from the perspective of someone looking at the code or writing it.

    If I were to rank them by personal preference the ordering would be
    1. C (clear and consise)
    2. D (kinda kludgy but does the trick)
    3. B (it's legal after all)
    4. A (I'd almost rather have less strong type checking then 'E' or 'F').
    5. E or F....the designer's intent has been completely lost.....to me

    > BTW, these are also in Accellera standard VHDL-2006-rev3.0, so
    > if your vendors were looking out for your interests, they would
    > have already should implemented these.
    >
    > Make sure to submit these as bug/enhancement requests. This is important
    > as this is what lets them know the VHDL community wants the new features.
    >


    I'll wait for one I like to see first.

    Kevin Jennings
     
    KJ, Jun 13, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Harri
    Replies:
    0
    Views:
    351
    Harri
    Dec 20, 2004
  2. amit

    help signed and unsigned in 64bits

    amit, Apr 7, 2004, in forum: C Programming
    Replies:
    14
    Views:
    556
    Dan Pop
    Apr 8, 2004
  3. kyrpa83
    Replies:
    1
    Views:
    627
    kyrpa83
    Oct 17, 2007
  4. Shannon

    stumped on syntax yet again!

    Shannon, May 7, 2008, in forum: VHDL
    Replies:
    22
    Views:
    1,534
    Rob Dekker
    May 12, 2008
  5. pozz
    Replies:
    12
    Views:
    747
    Tim Rentsch
    Mar 20, 2011
Loading...

Share This Page