Subject: Re: Dealign with data types - information from SV Basic Committee
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Sep 23 2002 - 11:26:47 PDT
> From owner-sv-cc@server.eda.org Mon Sep 23 09:49:09 2002
>
> Karen Pieper wrote:
> >
> > Yatin,
> >
> > the issues that we would like to transfer to your team are described in the following mail excerpts.
> > The reason we are forwarding it to your team is that these types seem to be being added in order to make
> > a closer connection to C. If the types are not necessary for C, or if typedefs are an acceptible way to
> > implement them, do we really need them as keywords in the language?
> >
> > From Cadence first mail on Section 3 issues (Can be found in the minutes
> > of the 7/8/02 meeting sent out by Stefen Boyd
I'd agree that it adds a lot of keywords. It might be simpler to add a single
keyword or operator to indicate that data is 2-state rather than 4 in a declaration
and use typedefs from old types. Using typedefs would also let you match the type
(int/char) to the OS if necessary, e.g.:
typedef integer #int; // # => 2-state
typedef integer [7:0] #char;
typedef integer [15:0] #short;
typedef integer [63:0] #long_long;
I would put these typedefs in a header file with the system and use something
like -
`include {c_types.sv}
- to include them ("" = user includes, {} SV system includes, <> C includes).
Since parsing isn't modular that would only solve (some of) the problem if you
see the conflicting Verilog before the typedefs, so it is probably a good idea to
add some compiler directives to indicate the language level, and to be able to
disable SV typing etc., e.g.:
`ifdef __SYSTEM_VERILOG__
`language_level IEEE 2001 // limit features <standards body> <release>
`endif
`include "old_stuff.v" // Non-SV code
`ifdef __SYSTEM_VERILOG__
`language_level // pop back
`endif
- that would disable potentially conflicting functionality for the included file.
I'd agree "void" isn't really necessary, it's just syntactic sugar.
Regards,
Kev.
> > ======================================================================
> > Section 3 - Issues with new data types and keywords (Steve/Cadence) [Basic]
> > - actual utility of char, shortint, longint, byte, shortreal
> > - non-orthogonality of definitions
> > - inconsistent with C definitions
> > - void type - is it necessary?
> > The new data types add a lot of new reserved words. From the viewpoint of
> > backward compatibility with Verilog, each of these should be carefully examined
> > for utility to offset the incompatibility introduced.
> > a. What exactly is the purpose of char? There is no interface to C defined, so
> > it can't be intended for values produced and consumed only by C. And Verilog
> > specifically only handles 8-bit ASCII values, so it can't manipulate char
> > values properly itself when they could be 16-bit Unicode. Trying to use them
> > with Verilog string literals, string I/O, or in combination with ASCII string
> > variables wouldn't work. If it isn't usable, it should be removed.
> > b. The shortint type has limited utility. There is no interface to C defined,
> > so it can't be needed to match struct layout at an interface. The 16-bit short
> > is rarely used in C, and can usually be replaced with a 32-bit int without any
> > problems. And in the unlikely event that a 16-bit int is really needed, it can
> > always be declared as a packed array of bit. The utility of shortint does not
> > appear to justify the addition of a reserved word.
> > c. The int type seems reasonable as a general purpose 2-state variable, similar
> > to the Verilog integer. However, one would expect orthogonality between the
> > 2-state and 4-state types. The int type is exactly 32 bits, while the integer
> > type is 32 bits or more. The types really should be orthogonal, rather than an
> > ad hoc collection.
> > d. The longint type probably has more utility than shortint, since it can't
> > always be replaced with an int. However, it doesn't correspond to a commonly
> > used C type except with a C compiler that is compiling for 64-bit. The need for
> > a 64-bit integer type in Verilog is limited, and can be declared as a packed
> > array of bit if necessary. It doesn't appear to justify the addition of a
> > reserved word.
> > e. The byte type could be justified by a desire to conveniently declare 2-state
> > strings. However, it does not appear that they can be used for this. String
> > literals can be assigned to arrays of char, but not to arrays of byte. Nor can
> > arrays of byte be used with string I/O or manipulated with Verilog operators or
> > in combination with other strings, which are packed vectors. This actually
> > makes the byte type less useful than an array of bits. And since "byte" is more
> > likely to be used as an identifier name in existing designs than most of the
> > other new types, it creates a more serious backward compatibility issue. The
> > limited utility does not appear to justify the addition of a reserved word that
> > is likely to match existing identifiers.
> > f. The bit type is needed to support 2-state vectors, though it carries some
> > risk of matching identifiers in existing designs.
> > g. The logic type has issues that will be discussed elsewhere. The name also
> > carries some risk of matching existing identifiers.
> > h. The fact that the unsigned keyword is officially reserved does not really
> > avoid backward compatibility issues. I don't know of any implementations that
> > actually reserve it, so it may appear as an identifier in existing Verilog
> > designs. This seems unlikely, and it does add significant utility.
> > i. The shortreal type adds limited utility. Again, without a direct interface
> > to C, there is no need to match an exact data type. The real data type can be
> > used instead. The use of reals in Verilog is rare enough that the
> > difference in
> > storage space and speed is unlikely to be significant. Also note that most
> > floating point operations in C are automatically done in double precision
> > regardless of the variable types. This means that an operation done with
> > floats in C could get a different answer than an equivalent operation done with
> > shortreal in SystemVerilog, due to different roundoff errors. So if the goal
> > is to match C floating point, then it fails.
> > j. The void type is unnecessary. It was added to C because C only has
> > functions, and void allows declaring a subroutine without a return value.
> > Verilog already has tasks, so it doesn't need void. There is nothing that can
> > be done with a void function that cannot already be done with a task. There is
> > no need to copy this type from C.
> >
> > From Cadence Second mail on Section 3 issues (Steve Sharp 7/8/02 at 14:14)
> >
> > 1. The functionality of the new integer data types can be gotten
> > without introducing new reserved words, by using typedef. For
> > example, the byte can be typedeffed as a packed array of 8 bits.
> > A common include file could be used to define all of these types,
> > and included whenever they were wanted. There is no reason to
> > predefine these in the language.
> >
> > Let me know if these need to bounce back to us.
> >
> > Thanks,
> >
> > Karen
>
>
This archive was generated by hypermail 2b28 : Mon Sep 23 2002 - 11:27:58 PDT