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

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?

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.

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.

As others observed earlier, the data types on nets extension does
not preclude an extension to the update semantics of Verilog.
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.

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.

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 Mon Nov 22 20:22:58 2004