Subject: [sv-bc] Re: SV-EC Proposal: Implicit Universal Data Type - Cliff Cummings to champion the proposal
From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Tue Jan 28 2003 - 02:30:21 PST
Cliff,
Are you sure you want to know what I think? ;)
OK, here are my thoughts in regards to your "implicit universal data type"
message...
First, your vague reference to "There will be new var or varports" leaves a
bad taste in my mouth. There are already too many data types in
SystemVerilog. We don't need another! I'll need to see the justification
for this proposal before I'm convinced it is "a good thing".
If I understand your proposal correctly, you are suggesting that a wire
become a schizophrenic data type that might behave as a 120 value net, with
wired-logic resolution and no storage, or it might behave as a 4-value reg,
with last-write stored variable resolution. I do not like the idea of a
dual-nature, context-dependent data type--especially if it means radically
changing the behavior of an existing Verilog data type. If I declare a
wire, I want the same behavior every time. If I declare a reg, I want the
same behavior every time.
I did not find in your proposal what should happen if a user (or model
library or IP model) sets the `default_nettype to something other than
wire. Should wor, wand, tri, trior, triand tri0, tri1 and trireg all have
the same schizophrenic behavior of sometimes having wired-logic/strength
resolution and sometimes last-write, stored value resolution? If so, I
don't like it. When I specify tri1, I am expecting wired logic (some
driver that is wired to an inferred pullup resistor) with pullup
resolution. Inferring a variable with some sort of last-write wins
pseudo-pullup behavior is NOT what I would expect or want.
You stated "I don't want to have to declare these universal wires except
for internal wire-buses". It's not that simple. A lot more than just
basic internal vectors will need to be explicitly declared. All packed
arrays, unpacked arrays, structures, unions, enumerated types, user-defined
types, and interface instances will also need to be explicitly
declared. High-level SystemVerilog models are much more likely to use more
of these new data types than regs. Therefore, the default "universal type"
you are asking for will likely only solve a small percentage of
declarations in SV models. It would save a lot more declarations in
existing pure Verilog models, but existing models already have declarations.
That said, I would still like SystemVerilog to infer variables the same as
Verilog infers wires. However, you have not (yet) convinced me to go to
the extreme that you are proposing. I like having a new (to Verilog) data
type that can be used in place of a wire or a reg, with a single driver and
no strengths. That data type can then be used in place of either a wire
(in most models), or a reg (in all models). The SV 3.0 logic data types
gives me most of what I want.
I like Dave Rich's proposal to add a semantic check that outputs and inouts
declared as any type of variable cannot be wired together. It forces the
user to declare a wire, when wired logic is needed. Indeed, at the
interconnecting module level, undeclared signals would default to a wire,
anyway, following Verilog-2001 rules. Explicit declarations for an
unresolved data type should be an error when there are multiple drivers.
In regards to a default type, I think the tool should make an intelligent
decision of inferring either a wire or a logic type. A wire should still
be inferred where one has always been inferred (for backward
compatibility). For other undeclared signals, a logic type should be
inferred. It seems to me that if the software tool can issue an error of
"undeclared variable", then the tool already has enough information to
infer a variable, instead of generating an error.
In other words, what I want, and what SV 3.0 almost gives me already, is:
- Within a module, I can explicitly declare everything a logic, and use
those declarations in procedures, continuous assignments, and connected to
instances of modules/primitive ports of any direction. Existing SV 3.0
semantic rules, plus Dave Rich's single driver proposal, will not allow
multiple drivers on the logic type, forcing me to select the appropriate
wired-logic net data type instead of shooting myself in the foot.
- Within a module, undeclared signals default to a wire if Verilog-2001
rules are met, and otherwise default to a logic. I would never get an
"undeclared variable" error. I would get an error if the default wire or
logic type is used as an array, structure, interface, etc., forcing me to
explicitly declare those types.
- Outside a module, at the module instance, I can explicitly declare
everything a logic. Dave Rich's single driver on a variable proposal will
not allow multiple drivers.
- Outside a module, at the module instance, undeclared signals will default
to a wire, following existing Verilog-2001 rules.
Your notes suggested that a proposal was made to replace "logic" with an
expanded "reg", so that the reg can do everything an SV 3.0 logic can
do. I'm fine with that. I cannot think of any place expanding the allowed
usage of reg would cause a backward compatibility problem. Yes, the term
"reg" has confused new Verilog users for years, but we've all survived the
ordeal. I find expanding the legal usage of reg types, but keeping the
true variable behavior, to more user friendly and intuitive than your
proposal of expanding the legal usage of wire AND giving it a
schizophrenic, context-sensitive dual behavior.
I like changing "logic" to "ulogic" and "bit" to "ubit". In part, it helps
make it clear that these are unresolved data types. Mostly, I like the
change, because it does not reserve keywords that are likely to show up in
existing Verilog models.
To summarize, I support your campaign to reduce the number of required
declarations in a module, but I do not support making wire a dual-behavior
data type. Nor do I support making any other data type have context
sensitive behavior. I prefer that wire be inferred following Verilog
rules, and SV add new rules for inferring reg or logic variables. I'm OK
with expanding the legal usage of reg and eliminating logic, as long as
rules require single driver usage, within and without a module. I'm also
OK with keeping logic, with those same restrictions. I like renaming logic
and bit to ulogic and ubit.
Keep up the campaign, and hopefully we can strike a compromise that reduces
necessary declarations, without radical changes to either Verilog or
SystemVerilog 3.0.
You asked for my opinion...
Stu
At 03:37 PM 1/27/2003, Clifford E. Cummings wrote:
>Subject: SV-EC Proposal: Implicit Universal Data Type - Cliff Cummings to
>champion the proposal
>
>Hi, All -
>
>At the SV-BC meeting, the users were sorely under-represented. I am asking
>for all users on these groups to offer email support for the following
>proposal.
>
>I tried to get the logic data type modified to become the universal data
>type that designers want, but at the all-day BC meeting last week, I was
>shot down and crashed and burned (lots of smoke and deep despair!)
>
>Per the SystemVerilog-BC minutes sent by Johny on Jan 25, 2003:
>
>There will be new var or varports with procedural last-assignment-wins
>behavior at a higher level of hierarchy - this was good.
>
>I think we passed Dave Riches proposal to prohibit multiple output or
>inout connections to a logic type at a higher level of hierarchy (this
>previously allowed last-assignment-wins behavior from two lower level
>modules that made procedural assignments to a logic variable) but I'm not
>sure which part of the minutes show this or if this was even actually voted.
>
>My proposal to allow multiple drivers to logic types and make logic the
>default data type in SystemVerilog was crushed (logic will not be the
>universal data type and must always be declared).
>
>The minutes show that a straw-poll vote was made to remove logic as a
>SystemVerilog data type. Other email discussion suggests that this was
>withdrawn but I do not see that in the minutes.
>
>And finally, I was given this action item:
>
>Cliff's implicit datatype can now be implemented via a new
>'default_nettype because local decisions can be made. However,
>we have not said that we would allow implicit declaration of
>procedurally defined variables. If Cliff wants to continue, he
>can make a proposal to EC.
>
>SystemVerilog-EC Proposal: The Universal Data Type
>
>After thinking this over and getting feedback from various designers on
>the committees, I think we have come full circle. I think we may have
>support for the universal data type that I first proposed back in the
>1997-1998 time-frame and detailed in an HDLCon 2000 paper (attached).
>
>I propose that "wire" become our universal data type.
>
>Inside of a module, if assignments are made to a wire type from a
>procedural block, the wire is treated like a reg with no strength
>information and the release command will treat the wire-variable like a
>reg (no immediate update - next updated by procedural assignment).
>
>Inside of a module, if assignments are made to a wire type from
>primitives, instances or continuous assignments (collectively referred to
>as driver assignments), the wire is treated like a wire with optional
>strength information and the release command will treat the
>wire-assignment like a wire (immediate resumption of driven value upon
>release). And of course, resolution of multiple drivers occurs.
>
>Jay Lawrence (and previously Peter Flake) had suggested that reg be the
>type that permits both driver and procedural assignments, but I strongly
>oppose that idea just because reg is already a misunderstood type name.
>Now the resolved default data type used in interfaces would be called reg
>(very confusing). I would like reg to become obsolete and largely
>forgotten in the future (except for backward compatibility).
>
>Jay Lawrence had rejected the notion of an undeclared type "morphing" into
>a reg or net type based on use, but that is exactly what happens with VHDL
>std_logic type. In VHDL you can make concurrent signal assignments or
>process assignments but not both, and you get resolution from concurrent
>signal assignments. This is what I want - except in true Verilog fashion,
>I don't want to have to declare these universal wires except for internal
>wire-buses.
>
>We already know that Verilog regs on output ports must be implicitly
>converted to a continuous assignment to drive a wire, so now it becomes a
>procedural wire that transforms into a continuous assignment wire hidden
>to the Verilog user.
>
>The nice thing about choosing a Verilog wire as the universal data type is
>that engineers already think of wires as connections, it is not a new
>keyword, and it is the default data type in Verilog so we don't have to
>create new rules for a default type that would not have to be declared.
>
>This way, we could also keep the logic type as the SystemVerilog
>unresolved type that requires declaration, which is what Matt Maidment of
>Intel wanted. I still think logic keyword should be changed to ulogic to
>more accurately reflect the unresolved nature and not confuse VHDL
>engineers that transition to SystemVerilog (same argument for bit/ubit).
>
>At the SV-BC meeting, the users were sorely under-represented. I am asking
>for all users on these groups to offer email support for this enhancement.
>
>Please - a vote of confidence for the universal default data type called wire!
>
>Attached is my HDLCon paper that gave greater detail on this proposal.
>
>Regards - Cliff Cummings
>
>
>
>
>----------------------------------------------------
>Cliff Cummings - Sunburst Design, Inc.
>14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
>Phone: 503-641-8446 / FAX: 503-641-8486
>cliffc@sunburst-design.com / www.sunburst-design.com
>Expert Verilog, Synthesis and Verification Training
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland-hdl.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland-hdl.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Tue Jan 28 2003 - 08:39:14 PST