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

 Cliff,

You say:
"VHDL does not force net/variable distinctions. Verilog should not force
them either."

Unless this has been changed radically by the 200X effort (I am not aware of

such a thing), this is a false statement.
VHDL has clear distinct contructs and distinct semantics for
variables and signals. A user needs to know the difference in order to write
VHDL code which is legal.

Francoise
    '

-----Original Message-----
From: owner-btf@boyd.com [mailto:owner-btf@boyd.com] On Behalf Of Clifford
E. Cummings
Sent: Sunday, November 21, 2004 11:37 PM
To: sv-bc@eda.org; btf-dtype@boyd.com
Cc: ieee1800@eda.org
Subject: DataTypes - Please vote no

Hi, All -

My apologies in advance to Kathy and the entire datatypes team for all the
hard work they have done, only to have me come late to the game and express
severe doubt about the datatypes proposal. Unfortunately, due to the volume
of SV email, volume of datatypes email and the Thursday schedule for
datatypes meetings, I have been unable to keep up in a timely manner. Due to
unfortunate circumstances, I had a few hours to catch up on what I think is
all of the datatype email that has circulated in the past month+

I found the email by Steve Sharp dated November 11, where Steve is
apparently explaining to Stu why the net datatypes are useful. I think I
have the same question(?) Why are net datatypes so important? Nobody that I
teach has asked for these capabilities, but almost everyone I teach is
disgusted at the declaration distinction between nets and regs.

In short. Most engineers (myself included) would like the tool to figure out
the distinction between a variable assignment and a net driver without the
requirement to change a declaration.

IMO - every common net/variable usage could be declared as a wire. All
existing net/variable rules would apply depending on whether a declared wire
was assigned within a procedural block (variable-rules) or whether it was
driven by a module, UDP, gate-primitive or continuous assignment
(net-rules). An error would occur if a user tries to make both procedural
and driver-assignments to the same identifier. First usage would determine
local usage-rules (whether the identifier will be treated like a net or a
variable in the local module).

This seems to satisfy one of the main reasons for the datatypes proposal,
allowing variable datatypes on nets. Seems like most identifiers could be
declared as a wire and datatypes applied. Since there are some limitations
for datatypes on nets (?), errors would be flagged if an assignment were
made to an illegally declared datatype.

The rest of the datatypes proposal could be reasonably adapted to common
wire/variable declarations.

Steve pointed out that designers do not think about making a procedural
assignment to a variable and then driving it onto a net. Or taking the value
from a net and procedurally assigning it to a variable. Steve is right. As
design engineers, we could care less. We like to make behavioral
descriptions for logic and then connect it to other logic. Until I joined
the Verilog Standards Groups, I did not even know that simulators frequently
run a procedurally assigned variable through a continuous assignment to get
it out of a module onto a resolved net.

VHDL does not force net/variable distinctions. Verilog should not force them
either.

Considering the amount of activity, explanation and confusion surrounding
the datatypes proposal, and since is does not address my fundamental concern
surrounding datakinds and datatypes, I will be voting no and will encourage
other members of the P1800 committee to vote no to this proposal.
I believe it is being rushed to meet a deadline and does not address far
more basic concerns that designers have with datakinds/types.

Sorry.

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,
SystemVerilog, Synthesis and Verification Training
Received on Mon Nov 22 08:31:24 2004