Re: 6/24 Datatypes Meeting Minutes

From: Francoise Martinolle (fm@cadence.com)
Date: Thu Jun 24 2004 - 10:42:54 PDT

  • Next message: Steven Sharp: "Re: 6/24 Datatypes Meeting Minutes"

    Steven,

    one correction to your minutes:
    You write :
    "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."

    you should have written:
    "Since a continuous assignment would read a 4-state net's
    value as 2-state, a z value could be lost in passing through a port."

    At 01:22 PM 6/24/2004 -0400, Steven Sharp wrote:

    >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:41:03 PDT and
    sponsored by Boyd Technology, Inc.