[sv-bc] Re: DataTypes - Please vote no

Hello Cliff,

I read your paper, and it does an excellent job of explaining your
issues with Verilog assignment semantics and your vision for making
the language easier to use. However, the problem that you describe
is not the problem that the "Data Types on Nets" extension is intended
to solve.

The "Data Types on Nets" extension is intended to solve the problem
that is described in Jonathan Bradford's erratum entitled "Complex
Data Types of Wires". In this case you have an object that is
unquestionably a net (a bidirectional with multiple drivers) and you
want to use one of the new integral data types (a packed struct)
to declare the net and pass it through the hierarchy.

The "Data Types on Nets" extension is narrow in scope. The extension
does not modify the existing Verilog network semantics, nor does it
change the SystemVerilog semantics for new data types. The extension
builds upon these two aspects of Verilog/SystemVerilog to extend a
convenient abstraction to nets.

There was not a lot of controversy in defining this extension in
the sv-bc. The syntax and semantics defined in this extension have
been implemented and are in use.

Your proposal and the "Data Types on Nets" extension are orthogonal.
They have different goals, and neither solves the problem that the other
addresses. Those who support the "Data Types on Nets" extension do not
necessarily support the extension that you describe. Yours should be
considered separately, on its own merits.

Regards,

Kathy

>Date: Mon, 13 Dec 2004 18:29:54 -0800
>To: Kathy McKinley <mckinley@cadence.com>
>From: "Clifford E. Cummings" <cliffc@sunburst-design.com>
>Subject: Re: DataTypes - Please vote no
>Cc: btf-dtype@boyd.com, sv-bc@eda.org, ieee1800@eda.org
>
>Hi, Kathy -
>
>Apologies for the late reply. I have been on the road 9 of the past 10
>weeks and most of those weeks I have had to listen to engineers complain
>about reg-wire declarations.
>
>At 08:22 PM 11/22/2004, Kathy McKinley wrote:
>>Hello Cliff,
>>
>>I found your last explanation to be very helpful. You are referring
>>to the fact that VHDL has both sequential signal assignment statements
>>and concurrent signal assignment statements. That is, in VHDL you can
>>update a signal from either a concurrent context or a behavioral block
>>(a process). Is this the enhancement that you seek in Verilog?
>
>Not quite. What I am requesting is a little different than what VHDL does.
>In VHDL. a concurrent signal assignment is just a shorthand for a process.
>In Verilog, a continuous assignment is a driver-assignment while an always
>block is a last-assignment-wins procedural assignment. I don't want the
>Verilog behavior to change. I just don't want to change the declaration
>every time I move assignments from procedural blocks to continuous
>assignments and back.
>
>I had a chance to ask Phil Moorby why he made the reg-wire distinction when
>he invented Verilog. Phil's response was when he invented Verilog, there
>were no synthesis tools and he really thought always blocks would be used
>to only build clocked logic. Phil put together a great language, but it is
>time to fix this mistake.
>
>What I (and most engineers want) is the ability to declare everything as a
>wire or wire bus and have first-usage determine if the behavior should
>follow existing procedural assignment rules or existing net-driver rules. I
>want absolutely no Verilog-behavior change, I only want declaration
>changes. Logic accomplishes this goal for unresolved types, I believe wire
>could solve the goal for resolved types. This is still fully backward
>compatible (you can declare the regs if you want to).
>
>Most of what RTL designers do with Verilog really does not include the need
>for the datatypes proposal. I am actually not completely against the
>proposal, if it would fix this major annoyance first.
>
>>I believe that the introduction of a VHDL-like sequential signal
>>assignment statement would be an enhancement to the execution
>>semantics of Verilog. I also believe that such an enhancement
>>is orthogonal to the data types on nets extension.
>
>Actually I do not want execution semantics changes. Just allow engineers to
>declare everything as net types and let the tool find first usage to
>determine semantics (and make the semantics equivalent to current Verilog
>behavior).
>
>I first addressed this proposal in Veirlog-2001 and was voted down (my
>proposal was not well formed). I later did a paper at HDLCON 2000 that did
>a better job of explaining the proposal, and some committee members said
>they understood the problem, but it was too late to make LRM changes. (See
>http://www.sunburst-design.com/papers/CummingsHDLCON2000_RegProposal_rev1_1.pdf
>)
>
>>The data types on nets extension is concerned with what values
>>a net can assume. For example, can a net take on values of an
>>enumeration data type or a packed struct data type? If so, how
>>does one specify that data type in the declaration of the net?
>>Are there any data types that are not allowed? For example, can
>>a net be declared to be of a class data type? These are the sort
>>of questions that the "data types on nets" proposal addresses.
>
>And all of this is good, if it would also fix the more glaring problem
>found by every RTL designer I teach.
>
>>As others observed earlier, the data types on nets extension does
>>not preclude an extension to the update semantics of Verilog.
>
>I am not convinced this is true. If we do not address this issue along with
>the datatypes proposal, we may find it impossible to make this change
>later; hence, my strong opposition to the datatypes proposal in its current
>form. I am also not convinced that power-2-state techniques, like those
>used by Lionel Bening of HP for the past ten years (described in our
>SNUG-Boston-2004 paper - also on my web sight) can be implemented if the
>4-state proposals are not careful enough.
>
>If we don't address this problem at the same time as the datatypes
>proposal, I don't think committee members will take time to consider it in
>the future. I have been fighting this battle for some six years now, and
>unfortunately, most of the datatypes work was done on a day that frequently
>finds me teaching at a customer site.
>
>Karen Pieper expressed her objection to Stu's `verilog_1995
>`verilog_1995_off (exact compiler directive keywords are not accurate)
>proposal because nobody had implemented it. Stu's `on-`off compiler
>directives proposal pales in scope and comparison to the changes proposed
>by the unimplemented datatypes proposal.
>
>>In fact, the proposal explicitly states that the update semantics
>>are not modified. We tried very hard to adhere to the scope that
>>was endorsed at the p1800 working group level.
>
>I do not want modified semantics. Just relaxed and sane declarations.
>
>>It is worth noting that data type orthogonality is an important
>>language design principle for VHDL. The VHDL signal assignment
>>semantics are not based on the values that VHDL signals can have.
>>VHDL supports a richer set of data types for its signals, and we
>>are trying to do something similar for Verilog.
>
>A worthy goal. If it simultaneously fixes the biggest complaint that I hear
>from VHDL users (no value in changing net-variable declarations just
>because an assignment was moved to a different place in the code), and from
>Verilog users, then I could support it.
>
>I will still try to put together more examples that show the painful side
>effects of the reg-wire declaration distinctions by the P1800 meeting for
>Wednesday.
>
Received on Wed Dec 15 05:34:27 2004