[sv-bc] AW: [P1800] DataTypes - Please vote no

Hi Cliff,

let me comment on your comparison with VHDL

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

VHDL does not distinguish between nets and regs/variables however is distinguishes between

* unresolved signals (written by single process or connected to single out port)
* resolved signals (written by single or multiple processes and/or connected to single or mutiple out port)
* (local) variables (written by single process)
* (global) shared variables (written by single or multple processes)

Further on, a special attribute feed_through for resolution functions was introduced to allow to optimize resolution
functions away. VHDL deals with the same issue as Verilog, how to make delays, multiple sources and resolution of
multiple sources visible. VHDL makes it slightly different than Verilog, but it also introduces several object types
here.

Further on, VHDL supports types to be applied to all kinds of objects if even possible. I.e. especially with my
VHDL backgound, I would not understand to have types on variables but not types on nets.

Kind regards, Wolfgang

-----Ursprüngliche Nachricht-----
Von: owner-ieee1800@eda.org [mailto:owner-ieee1800@eda.org] Im Auftrag von Clifford E. Cummings
Gesendet: Montag, 22. November 2004 05:37
An: sv-bc@eda.org; btf-dtype@boyd.com
Cc: ieee1800@eda.org
Betreff: [P1800] 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 Sun Nov 21 22:22:43 2004