Re: Requesting datatypes feedbac

From: Daryl Stewart (daryl.stewart@tenison.com)
Date: Thu Jul 01 2004 - 03:07:17 PDT

  • Next message: Alec Stanculescu: "Re: Requesting datatypes feedback"

    Alec Stanculescu wrote:

    >Shalom and Daryl,
    >
    >It seems that we agree on what "kind" and "type" represent implicitely
    >in V2K and on what they should represent explicitely in V2K5.
    >
    >It is important to agree on whether complex data types must contain
    >only sub elements of the same kind or not (I hope for a yes). Also, for
    >objects of kind wire, the resolution shall be done at the level of the
    >"full strength" elements only.
    >
    I would hope a complex data TYPE can only contain members which are
    themselves TYPEs and not kinds at all. (Is D7 of datatypes donation
    relevant?)
    The declaration of an actual object of the complex data type would then
    denote the kind of the object's members.
    This is another incentive for reg as kind since taking the example from
    the datatypes donation section 2.7

    typedef struct
    {
      word_kind kind;
      union {
        logic [31:0] long_word;
        logic [1:0][15:0] short_words; }
      u; } word_type;

    then if reg were a type we could rewrite the above with reg in place of
    logic, then do
    reg word_type word;
    or presumably the unfortunate
    wire word_type word_w; // wire containing regs?

    I guess this counts as an example where an ambiguity would arise, but it
    would be resoved by explicitly not using "var" in the typedef. So we'd
    need a special case rule like "reg is not implicitly of kind var within
    a typedef".

    Is there any idea of a complex kind? Or a complex object? Modules as
    types in C4 of datatypes donation?

    >Indeed, the wording of the Cadence data type donation views
    >signed/unsigned as properties of the vector type, thus making signed
    >vector a subtype. Personally, I prefer to consider a signed vector
    >type and an unsigned vector type. However, this is a detail that can
    >be agreed upon within the working group.
    >
    Thinking of a subtype, which is a restriction on a type, as a type
    generally presents no problems, unless you forbid subtyping of subtypes...

    >Shaloms, points out that in SV there are in fact what amounts to two
    >kinds of variables, and one knows which one it is by how it is
    >used. If it is written by one continuous assignment it should be
    >written only by that one CA, and if it is not written by any CA nor is
    >it passed as an actual to a the output of a module instantiation, or
    >primitive, then it can be written by any number of procedural
    >assignments. How these two kinds of variables will be supported will
    >again be decided by the working group and is a detail.
    >
    OK

    >Shalom raises the point that objects of kind event do not have values.
    >I view this also as a detail to be delt with by the working group. In SV
    >objects that are events have the type boolean and equality and
    >inequality operators are usable on them.
    >

    Sorry, they are definitely not booleans:
    [SV 3.1a S.13.7 Event variables]
    "An event is a unique data type with several important properties.
    When one event is assigned to another the synchronization queue of the
    source event is shared by both the source and the destination event."

    The result of 13.7.3 is that if you test (Ea == Eb) it is ONLY true if
    somehow Ea and Eb share the same source event. It is not true if they
    are different events which happen to have been triggered together. (Its
    a referential equality not value equality)

    OTOH, the *property* triggered of an event (e.g. Ea.triggered)is a
    boolean, although you cannot directly assign to it (only implicitly by
    triggering it)

    [SV 3.1a S.13.5.4 Persistent trigger: triggered property]
    "SystemVerilog can distinguish the event trigger itself, which is
    instantaneous, from the event s triggered state, which persists
    throughout the time-step (i.e., until simulation time advances). The
    triggered event property allows users to examine this state."

    [SV 3.1a S.13.7] uses the term "data type" but V2K5 would use "kind", I
    assume.

    >
    >There was a question brought up regarding value vs strengths for
    >objects of kind wire. In V2K the content of a wire (I forced myself
    >not to use the word value) can be viewed as an interval having it's
    >limits described by the result of the Cartesian product of a
    >value-set of two values (0 and 1) and another strength-set of seven
    >strengths, requiring a total of 8 bits for the representation of such
    >content/value.
    >
    >
    Absolutely - we definitely agree on the cartesian product!
    Shalom Bresticker wrote:

    >Is this described in one of your papers?
    >
    Yes, briefly, but my pages at Cambridge University have been downsized
    ;) and it wasn't published anywhere else.
    I'll dig out a copy from home and send you it.

    Alec Stanculescu also wrote:

    >This state of affairs in V2K can be described in terms of types, as having
    >objects of kind wire be of either what I called type "full strengths"
    >or type 4-state depending on how the particular object is used. Such types
    >do not exist in V2K, but if introduced in V2K5 would describe well the
    >situation in V2K and would allow to describe complex data types for
    >objects of kind wire, not in terms of reg and wire (since these are
    >kinds) but in terms of "full strengths" and 4-state).
    >
    >Best regards,
    >
    >Alec
    >

    But I would still prefer to describe 4-state as a projection (view of)
    the underlying strength. As a simple example, consider an inout:
    V2K1 5.6.6 says you can model "...an inout, [as] a nonstrength-reducing
    transistor connecting the local net to an outside net"

    If I have to decide whether my local net is "full-strength" or "4-state"
    I must know its use in the instantiating parent (i.e. does my parent
    drive/resolve it with signals of the same strength or different
    strengths?). What if I have more than one parent, with different uses?
    What if I am providing an encrypted, separately compiled IP block to
    customers? I agree that the decision would be made to some extent by any
    sensible implementation, but I don't believe it is necessary for the
    standard to dictate this decision as mandatory. Describing use
    (reading/writing) as employing a projection is, to my mind, a cleaner
    abstraction.
    Furthermore, unless the intention is to allow direct assignment of
    particular strengths (requiring a syntax for ambiguous strengths ;) then
    there is no need to define their collection as a particular type.

    cheers
    Daryl 

    -- 
Tenison Technology
System Emulation in Software

    Tel:   +44 1223 706479
Fax:   +44 1223 470030
Email: Daryl.Stewart@tenison.com
Web:   www.tenison.com

    This archive was generated by hypermail 2.1.4 : Thu Jul 01 2004 - 03:05:42 PDT and
    sponsored by Boyd Technology, Inc.