Subject: Re: Dealign with data types - information from SV Basic Committee
From: Yatin Trivedi (trivedi@pacbell.net)
Date: Mon Sep 23 2002 - 10:22:44 PDT
That subject line should have read "Dealing with" rather than "dealign
with"
I guess typos can be really bad - my fingers were de-aligned!
Yatin
Yatin Trivedi wrote:
>
> 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
> >
> > ======================================================================
> > 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 - 10:12:31 PDT