[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 18:26:11 2004