Subject: [sv-bc] RE: SV-EC Proposal: Implicit Universal Data Type - Cliff Cummings to champion the proposal
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Mon Feb 03 2003 - 10:23:58 PST
At 07:53 AM 1/28/03 -0500, Jay Lawrence wrote:
>Cliff,
>
>I apologize if you seemed bullied, beaten, or bashed in the face-to-face.
As I expressed in the meeting. There are 2 issues here, not 1. We were
discussing one issue, you wanted to discuss a second. I believe that is
still the case.
>
>The discussion at hand first was how 'variable' objects act if used in a
continuous assignment or when attached out input, output, and inout ports.
This was not specifically reg vs. logic. It pertains to all 'variables' of
which SystemVerilog now has many.
>
>The decisions made were all 'straw poll' votes, not final but we made
great progress. The behavior of continuous assignments was decided; input
and output were defined; and inout was discarded in favor of 'var' to
indicate the shared variable semantics it implies. Now that we know what it
means to connect a variable to a port, or assign to it with a continuous
assignment, we can move on to discussing the second topic.
Agreed, and the different shared variable port type makes sense to me. Less
confusion than piggy-backing onto existing hardware-behaved input, output
and inout ports.
>Can we have a kind of object that is undeclared (or declared) and takes
on the semantics of either a variable or a net based on how it is used?
>
>Sure, we could define such a thing. But I don't think it would be reg or
wire. Today wire is really the type you are looking for because it is
implicitly declared and takes on the characteristic of what it is hooked
to. Of course, only wires can be hooked to ports so the decision is
trivial. Now that we have variables on ports we would just need to decide
the rules for defaulting whether implicit objects are a variable or net
based on the port types they are hooked to. This sort of analysis could
also be done for objects that are procedurally assigned.
>
>This does get sort of nasty with netlists because the information about
the ports is not known in Verilog until you see the module definition. Thus
a system would have to defer this decision to elaboration. This is no big
deal for simulation, I can't speak for synthesis.
>
>I suggested in the meeting that this become a whole new kind of object.
So if you wanted to declare it you could. Something like univar, copper, ....
>
>I've cut a couple snippets of your mail for more specific comment below.
>Cliff> Jay Lawrence (and previously Peter Flake) had suggested that reg
be the type that permits both driver and procedural assignments, but I
strongly oppose that idea just because reg is already a misunderstood type
name. Now the resolved default data type used in interfaces would be called
reg (very confusing). I would like reg to become obsolete and largely
forgotten in the future (except for backward compatibility).
>
>I completely agree that 'reg' should disappear. 1364-2001 did a good job
of cleaning up references to 'reg' and making them 'variable'. We should
carefully consider this because we are about to adopt syntax for tasks and
functions that using the keyword 'var' to mean pass by reference.
>
>Cliff> Jay Lawrence had rejected the notion of an undeclared
type "morphing" into a reg or net type based on use, but that is exactly
what happens with VHDL std_logic type. In VHDL you can make concurrent
signal assignments or process assignments but not both, and you get
resolution from concurrent signal assignments. This is what I want -
except in true Verilog fashion, I don't want to have to declare these
universal wires except for internal wire-buses.
>
>As you can see from my comments above I am not 'rejecting' the notion of
such an object. It is just a different discussion from the behavior of
variables when continuously assigned or attached to ports. If the Verilog
world wants even more implicitly declared stuff that could possibly hide
design errors caused by typos bringing new objects into existence, so be
it. As I said in Tuesday's meeting, this is just more rope given to the
Verilog user to hang themselves, but as a vendor, if the customer tells me
they need more rope, I'll sell'em rope.
Sell me rope ;-)
I only want to declare variables (net or reg) that are more than one bit
and that are not already declared in a port declaration and really I am
only interested in the size (let the tool figure out the type and tell me
if I am using it inconsistently). Having done VHDL ASIC design, I found
equal probability that I would misspell the identifier name in a
declaration as I would misspell the identifier name in my RTL description.
The difference is, VHDL would now flag my good code as bad, and I
frequently spent more time trying to figure out why my good code was not
bad as opposed to discovering the typo in the declaration. If vendors think
this is less rope, I want more rope.
If a user wants less rope, they can now set `default nettype_none and then
they can get all of the "benefits" of required declaration.
>To set the record straight, VHDL types are completely different
(unfortunately and it is not too late to fix this ;). There are 2 kinds of
objects in VHDL 'signal' and 'variable'. Both can take on (almost) any
type. Signals are always used on ports, with the '<=' signal assignment
operator, and with subprogram parameters explicitly of class signal.
Variables are used with the variable assignment operator ':=' and as
subprogram parameters. They are never intermingled by allowing variables on
ports or signals to be procedurally assigned. The resolution of a VHDL type
is explicitly declared in the case where it is a signal class object and it
is multiply driven. It is impossible to create any driver, much less
multiple drivers, to a variable class object.
I have received email from Erich Marschner educating much better on how
VHDL types work and I now know that I do not want VHDL behavior. There is
more to std_logic than I had remembered.
>As I've said in other emails, the thing we are missing with types in
SystemVerilog is allowing them to be used for both variable and net kinds
of objects. Today they only work on variables. As I did on Wednesday, I
encourage you to further develop a proposal on how implicit objects can be
either variables or nets based on how they are used.
My proposal is to allow wires, declared or implicit, to allow EITHER
procedural assignments OR continuous assignments within a module and that
the behavior of the identifier is consistent with either wires or regs,
depending on how they are used in the module. Advantages:
(1) I don't add any new keywords
(2) I don't have to change the declaration when I change from
procedural to continuous assignments or vice versa - wire can now be used
as a generic, sized variable
(3) Wire is already the default type
(4) I get the size that I need (which is really all I care about)
(5) Resolved data type within the module if I make multiple-driver
assignments to the identifier
(6) Syntax error if I try to mix procedural and driver assignments to
the same variable
(7) Does not break any existing designs
Sell me rope and I will help sell your rope to the users (this should be an
easy sell).
>Jay
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, Synthesis and Verification Training
This archive was generated by hypermail 2b28 : Mon Feb 03 2003 - 10:23:23 PST