Subject: Dealign with data types - information from SV Basic Committee
From: Yatin Trivedi (trivedi@pacbell.net)
Date: Mon Sep 23 2002 - 09:59:46 PDT
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 - 09:49:27 PDT