6/24 Datatypes Meeting Minutes

From: Steven Sharp (sharp@cadence.com)
Date: Thu Jun 24 2004 - 10:22:08 PDT

  • Next message: Francoise Martinolle: "Re: 6/24 Datatypes Meeting Minutes"

    Attendees:
            Steven Sharp
            Atsushi Kasuya
            Shalom Bresticker
            Tom Fitzpatrick
            Francoise Martinolle
            Dave Rich
            Kurt Baty

    Action Items:

            - Dave to come up with an example where the suggested set of
              default "kind" rules do not give backward compatibility with
              both Verilog-2001 and SystemVerilog (or perhaps one where the
              keyword "var" would need to be added).

            - Steven to consider any other problems with the proposed 2-state
              approach for nets.

    Summary:

    Minutes from last minutes approved.

    More discussion of "reg" issue. Question to be raised at BTF level:

      Should "reg" be an object kind meaning a variable, as contrasted with
      kinds such as nets (wire, tri0, wor, etc.), parameters, and functions?
      Or should "reg" be a type, equivalent to "logic", which can be used in
      a declaration of a variable, net, parameter or function? The latter
      might require the addition of another keyword (such as "var") to allow
      unambiguous declaration of variables in some situations.

    Discussion then turned to 2-state. Steven made some comments about the
    proposed 2-state net approach, which would keep values as 4-state for
    "network" contexts such as resolution, but convert them to 2-state when
    read elsewhere.

    Kurt had also suggested this for variables. Steven noted that it would
    not be visible whether variables were stored as 2-state or 4-state, so
    doing this would not affect simulator's ability to actually store them
    as 2-state if desired. This is based on the assumption that all ways
    of reading a variable are ones that would convert it to 2-state.

    Steven then pointed out that input and output port connections are
    defined to be a continuous assignment from the source side to the
    sink side. Since a continuous assignment would read a 2-state net's
    value as 2-state, a z value could be lost in passing through a port.
    However, if the port was collapsed, then both sides would become a
    single net, and a z value would not be lost. This would make the
    optional port collapsing visible, which could create portability
    problems between simulators.

    Some other attendees argued that ports don't act like continuous
    assignments, but pass strength. Transistor-level designs often rely
    on this behavior. Steven maintained that this worked only because most
    ports get collapsed. He is aware of at least one commercial simulator
    that does not collapse certain ports. This only occurs for vector nets,
    which may avoid the transistor-level issue.

    It was suggested that the rules for port connections and/or the reading
    of nets as 2-state could be altered to ensure that 4-state values would
    be passed through ports even if they were not collapsed. Steven
    acknowledged that this could probably be made to work, with an appropriate
    set of rules. General feeling was still that this approach would work.

    [Further comment not brought up at meeting: Inout ports are not defined
     as continuous assignments, but in a way that requires them to pass
     strengths. And if a port is declared as an input but used as an
     output, or vice-versa, a simulator must either coerce it to inout, or
     give a warning that it has not done so. These rules essentially require
     port collapsing in some situations, or warnings if it is not done.
     --Steven]

    Various people will be on vacation in 2 weeks.

    Therefore the next meeting will be in 4 weeks, July 22.

    This archive was generated by hypermail 2.1.4 : Thu Jun 24 2004 - 10:20:18 PDT and
    sponsored by Boyd Technology, Inc.