[sv-bc] SV-EC Proposal: Implicit Universal Data Type - Cliff Cummings to champion the proposal


Subject: [sv-bc] SV-EC Proposal: Implicit Universal Data Type - Cliff Cummings to champion the proposal
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Mon Jan 27 2003 - 15:37:39 PST


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



This archive was generated by hypermail 2b28 : Mon Jan 27 2003 - 16:34:26 PST