From: Steven Sharp (email@example.com)
Date: Thu Jun 24 2004 - 10:22:08 PDT
- 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.
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
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.
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
sponsored by Boyd Technology, Inc.