Subject: [sv-bc] RE: SV-EC Proposal: Implicit Universal Data Type - Cliff Cummings to champion the proposal
From: Jay Lawrence (lawrence@cadence.com)
Date: Tue Jan 28 2003 - 04:53:37 PST
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 ouput 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. 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 univvar,
copper, ....
I've cut a couple snippets of your mail for more specific comment below.
>
> 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.
>
> 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
existance, 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.
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.
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.
Jay
This archive was generated by hypermail 2b28 : Tue Jan 28 2003 - 04:54:21 PST