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

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.

>Kathy
>
> >Date: Mon, 22 Nov 2004 18:23:32 -0800
> >To: sv-bc@eda.org, btf-dtype@boyd.com
> >From: "Clifford E. Cummings" <cliffc@sunburst-design.com>
> >Subject: [sv-bc] Re: DataTypes - Please vote no
> >
> >Hi, Steve -
> >
> >Also good discussion by Wolfgang, Francoise and Alec. So far, I believe the
> >discussion is very well reasoned and non-emotional. Differences of opinion
> >will arise. More discussion below.
> >
> >At 03:50 PM 11/22/2004, Steven Sharp wrote:
> >>Cliff,
> >>
> >>You have described an enhancement you would like to the language. This
> >>proposal does not provide that enhancement, and was not intended to. You
> >>are suggesting that is a reason to vote against this proposal.
> >
> >True.
> >
> >>None of the other proposals that have been made to the BC have provided
> >>that enhancement either, and were not intended to. And yet you have never
> >>suggested that as a reason for voting against them.
> >
> >Also true, but the other proposals were not as closely related to this
> >proposal.
> >
> >>This proposal does not conflict in any way with your desired proposal. In
> >>fact, it removes one of the differences between variables and nets in
> >>SystemVerilog, which brings us one step closer to what you have said you
> >>wanted. The fact that it is a smaller step than you wanted is not a good
> >>reason to reject that advance.
> >
> >I disagree. The further we move in the direction of the datatypes proposal,
> >the harder it becomes (or the less likely anyone will be interested in) to
> >make the important changes that I, and other hardware engineers have been
> >requesting for years.
> >
> >I will try to find time in the next few days to put together a number of
> >annoying examples made necessary by the declaration distinction between
> >nets and variables.
> >
> >My earlier statement was misinterpreted:
> >"VHDL does not force net/variable distinctions. Verilog should not force
> >them either."
> >
> >My statement should have been:
> >"VHDL does not force Verilog-like-net/Verilog-like-variable distinctions."
> >
> >Having done ASIC design in both Verilog and VHDL, I was referring to the
> >fact that VHDL engineers can declare a signal and make either process or
> >concurrent signal assignments to the same signal (within the bounds
> >resolved and unresolved rules) without any declaration change.
> >
> >I have found almost equally split recommendations regarding the use of VHDL
> >variables in RTL coding among my VHDL colleagues. Some say to avoid them
> >and only use signals, while others say to use them for
> >simulation-efficiency reasons within a process. I was not trying to comment
> >on VHDL variables. I was referring more to VHDL signals (resolved or
> >unresolved).
> >
> >I find that new and self-taught Verilog users find two Verilog semantics to
> >be confusing: (1) nets -vs- regs, and (2) blocking -vs- nonblocking
> >assignments. We can fix the first issue very easily with what I have
> proposed.
> >
> >Whenever I teach a Verilog class to a group of strong VHDL coders, the VHDL
> >engineers ask why they had to change the declaration when they moved the
> >LHS continuous assignment variable into a procedural block LHS assignment.
> >They ask what value was there in the language forced by the declaration
> >change. I always answer, it is just a silly rule of the Verilog language.
> >
> >Alec pointed out that if tools could figure out which is which but that the
> >semantics would have to be explained. Alec is right, but I have to do this
> >anyway. Engineers have to understand that continuous assignments, etc. are
> >all driver assignments, equivalent to VHDL std_logic. Procedural
> >assignments are behavioral assignments and last assignment wins. For
> >SystemVerilog, logic & bit-type assignments allow either one driver or one
> >procedural-source assignment like VHDL std_ulogic. The point is, engineers
> >already have to understand the driver-or-behavioral assignment nature to do
> >good RTL coding. The added annoyance of changing declarations does not add
> >value. I would disagree with Alec that reg/wire declarations make the code
> >more readable. The only real beneficiary seems to be the EDA tool software
> >engineers (they can determine object semantics before it is used).
> >
> >The other difference between VHDL and my proposal is that VHDL processes
> >actually do create drivers onto std_logic signals and can be combined with
> >other concurrent assignments to the same signal. Under my proposal, Verilog
> >would not allow procedural blocks and continuous assignments, etc., to
> >drive a common wire. I actually like this distinction better than the
> >VHDL-way, but that is just personal preference.
> >
> >Occasionally, I find engineers that want the ulogic testing addressed by
> >SystemVerilog and I believe further enhanced within the datatypes proposal,
> >but in reality, most hardware engineers could care less. Why? Because there
> >is no such thing as ulogic hardware. All real hardware-outputs resolve, but
> >I acknowledge that having the datatype for checking for multiple drivers is
> >useful.
> >
> >The reg/wire declaration requirements are completely foreign to hardware
> >engineers, which is why they are so confusing to new and self-taught
> >Verilog engineers. Every error message on this subject is rather foreign to
> >hardware engineers: "illegal left-hand-side assignment," illegal assignment
> >to wire," "illegal lvalue assignment." I tell engineers to get used to
> >these messages because they going to see them a lot. I tell them the
> >message should really say, "you made an illegal assignment to a Verilog
> >net-type. Did you forget to declare a reg-variable for the variable xxx on
> >line ##?"
> >
> >The point I want to make is that the datatypes proposal addresses
> >interesting and sometimes useful datakind and datatype side-issues, while
> >completely ignoring the larger issue. I compare this to choking on a peanut
> >while swallowing an elephant without complaint.
> >
> >For this reason, I encourage a no-vote on the datatypes enhancements unless
> >they incorporate the larger issue of silly declaration requirements.
> >
> >I personally think adapting the datatypes proposal to commonly declared
> >net-types that are automatically recognized by tools as either driver-type
> >or procedural-type variables would further simplify some of the exceptions
> >that currently are in the datatypes proposal.
> >
> >I think there is a good reason to vote no to a partial and perhaps
> >debilitating solution. Passing this proposal without addressing the net-reg
> >issue could make the latter much more difficult to fix at a later date.
> >
> >>Steven Sharp
> >>sharp@cadence.com
> >
> >As one of President Clinton's Impeachment Trial Lawyers so famously stated,
> >"reasonable people can disagree!"
> >
> >Regards - Cliff

----------------------------------------------------
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, SystemVerilog, Synthesis and Verification Training
Received on Tue Dec 14 10:02:16 2004