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: Tue Jan 28 2003 - 12:08:17 PST
Hi, Stu -
Just respond to the reflectors and not to me personally. I will still get 3
copies!
A few answers and clarifications.
I guess the first clarification is I am not really seeking a
universal-universal replace-all data type.
I want the ability to make either procedural assignments OR resolved
continuous assignments to the same variable without declaring that
variable, except in the case of internal vector-variables/busses or
interface declarations. If I could make a procedural assignment to either a
declared or undeclared wire, I believe that gives me everything I want.
The other request is to refrain from the somewhat emotional and labeling
adjectives "schizophrenic," "radical" and "extreme."
Now on to the individual points.
At 02:30 AM 1/28/03 -0800, Stuart Sutherland wrote:
> Cliff,
>
> Are you sure you want to know what I think? ;)
>
> OK, here are my thoughts in regards to your "implicit universal data
type" message...
>
> First, your vague reference to "There will be new var or varports"
leaves a bad taste in my mouth. There are already too many data types in
SystemVerilog. We don't need another! I'll need to see the justification
for this proposal before I'm convinced it is "a good thing".
This was not my proposal but I thought it was a good idea. The problem that
is being addressed is the old SV 3.0 behavior of logic that permits
last-assignment-wins behavior through a port, which is why I think your
slides on logic being the universal data type are quite misleading.
I think I finally convinced people that modeling two flip-flops in two
separate modules making assignments to a logic output and then connecting
the outputs together at a higher level to another logic variable and
getting last-assignment-wins behavior is not consistent with any known
hardware. That is why we killed that "logic" behavior for SV 3.1(?)
I think the group decided that some engineers do want some type of
last-assignment-wins behavior for architectural modeling and that making it
work through existing Verilog ports would only confuse hardware-thinking
engineers. The concept of a "var" or "varport" distinguishes that this is
no longer a hardware connection but a behavioral connection. Made sense to
me. That is why I supported this idea.
> If I understand your proposal correctly, you are suggesting that a wire
become a schizophrenic data type that might behave as a 120 value net, with
wired-logic resolution and no storage, or it might behave as a 4-value reg,
with last-write stored variable resolution. I do not like the idea of a
dual-nature, context-dependent data type--especially if it means radically
changing the behavior of an existing Verilog data type. If I declare a
wire, I want the same behavior every time. If I declare a reg, I want the
same behavior every time.
What you call schizophrenic, I call flexible. If I declare or not-declare a
wire and make assignments from drivers I want wire-behavior (same as
today). If I declare or not-declare a wire and make assignments from
procedural blocks, I want reg-behavior (and if the variable is an output,
it will turn into an output outside of the module - same as today). If I
declare or not-declare a wire and try mixing the assignments, I get a
syntax error. I forget to declare my reg-variables all the time - the
difference is now they will work without correcting all the "illegal
left-hand side assignment" errors.
> I did not find in your proposal what should happen if a user (or model
library or IP model) sets the `default_nettype to something other than
wire. Should wor, wand, tri, trior, triand tri0, tri1 and trireg all have
the same schizophrenic behavior of sometimes having wired-logic/strength
resolution and sometimes last-write, stored value resolution?
No - I neglected to mention that making a declaration of an explicit
non-wire type would require the explicit type and now you would either have
to declare procedural variables as either explicit variables or as explicit
wires. Side note - I have never used a `default_nettype on any real design,
only in class examples, and a `default_nettype of "logic" would give
default-unresolved behavior and a `default_nettype of "none" would still
force all declarations to be made. Now if you add a `default_nettype of
"logic" to a design, you could quickly identify all of the multi-driver
connections in your design. This would be useful.
> If so, I don't like it. When I specify tri1, I am expecting wired logic
(some driver that is wired to an inferred pullup resistor) with pullup
resolution. Inferring a variable with some sort of last-write wins
pseudo-pullup behavior is NOT what I would expect or want.
I am not advocating this but Jay Lawrence suggested in the last meeting
that continuous assignments be permitted to reals and time and all other
variable types. At first I rejected the idea, but it may have merit. It
would not break any existing design and one could now declare a real and
EITHER make a procedural assignment or a continuous assignment to the type,
which seems to support real ports (good for AMS).
> You stated "I don't want to have to declare these universal wires except
for internal wire-buses". It's not that simple. A lot more than just
basic internal vectors will need to be explicitly declared. All packed
arrays, unpacked arrays, structures, unions, enumerated types, user-defined
types, and interface instances will also need to be explicitly
declared. High-level SystemVerilog models are much more likely to use more
of these new data types than regs. Therefore, the default "universal type"
you are asking for will likely only solve a small percentage of
declarations in SV models. It would save a lot more declarations in
existing pure Verilog models, but existing models already have declarations.
Let me clarify - I do not want to declare the most common types, wire and
reg, except for internal buses. Using anything other than these defaults
should still require declaration and that makes perfect sense to me. I am
not asking for the universal-universal data type.
> That said, I would still like SystemVerilog to infer variables the same
as Verilog infers wires. However, you have not (yet) convinced me to go to
the extreme that you are proposing. I like having a new (to Verilog) data
type that can be used in place of a wire or a reg, with a single driver and
no strengths. That data type can then be used in place of either a wire
(in most models), or a reg (in all models). The SV 3.0 logic data types
gives me most of what I want.
The other reason I like flexible wire declarations is because if I don't
care about potential problems due to resolution of multiple drivers (and I
don't - it has never been a problem in any of my designs that I did not
quickly find and fix), I can now declare all of the common connections in
an interface to be of type wire.
In the SystemVerilog presentations that I have seen you make, you have a
partial example where all of the interface variables are declared to be
type wire. If you have not fixed this, you should. The only interface
variables that should be wire-type are multiply driven variables, such as a
bi-directional data bus. When you declare all of the interface variables to
be of type wire, you prohibit any module from making a procedural
assignment to the interface variables. If we pass my proposal, your
interface slide will work perfectly and that is exactly what I would like
to do when I make interface declarations - everything is a wire and I am
done. No more thinking about the different data types for interfaces
(except of course structures, unions, etc.)
> I like Dave Rich's proposal to add a semantic check that outputs and
inouts declared as any type of variable cannot be wired together. It
forces the user to declare a wire, when wired logic is needed.
And breaks some existing designs.
> Indeed, at the interconnecting module level, undeclared signals would
default to a wire, anyway, following Verilog-2001 rules. Explicit
declarations for an unresolved data type should be an error when there are
multiple drivers.
I think this is the idea behind logic and that is fine. If you declare
everything to be of type logic, you can get the multi-driver checking.
> In regards to a default type, I think the tool should make an
intelligent decision of inferring either a wire or a logic type. A wire
should still be inferred where one has always been inferred (for backward
compatibility). For other undeclared signals, a logic type should be
inferred. It seems to me that if the software tool can issue an error of
"undeclared variable", then the tool already has enough information to
infer a variable, instead of generating an error.
I like this idea for modules but not for interfaces. I would like to give
one of the following rules of thumb for interfaces:
(1) If your design does not permit multiple drivers, declare all
interface variables to be of type logic.
(2) If your design does permit multiple drivers, declare all interface
variables to be of type wire.
I think this makes both sides happy.
> In other words, what I want, and what SV 3.0 almost gives me already, is:
>
> - Within a module, I can explicitly declare everything a logic, and use
those declarations in procedures, continuous assignments, and connected to
instances of modules/primitive ports of any direction. Existing SV 3.0
semantic rules, plus Dave Rich's single driver proposal, will not allow
multiple drivers on the logic type, forcing me to select the appropriate
wired-logic net data type instead of shooting myself in the foot.
Existing SV 3.0 permits multiple last-assignment-wins assignments to logics
at a higher hierarchical level (fixed in SV 3.1(?)) - which is why I say
you should not call logic the universal data type, even for SV 3.0)
As long as we are using body-part analogies, using the fingers that I find
on one hand, I can count the number of engineers I have talked to in the
past decade that insisted on having an unresolved type. To count the number
of engineers that have complained about reg -vs- wire and having to change
declarations when they change assignment types, would require all of the
fingers from the Mormon Tabernacle Choir.
I am sure that I have accidentally connected multiple drivers by mistake at
least a few times in the past 11 years, but I don't remember those
occasions because the bug is obvious in simulation, easily found and
quickly fixed. This is hardly shooting oneself in the foot. It rarely
happens and is quickly fixed. There is no danger of a simulation mismatch
between pre- and post-synthesis simulations.
On the other hand, "illegal left-hand side assignment" or the opposite
"illegal assignment to reg" messages are an every day occurrence. Again,
they are easy to fix but to me, the required changes are practically
worthless changes, required to make my compiler compile. When I teach a
class and tell new users that I am trying to get this fixed, I always
receive full support to get this changed, even from engineers with a VHDL
background.
> - Within a module, undeclared signals default to a wire if Verilog-2001
rules are met, and otherwise default to a logic. I would never get an
"undeclared variable" error. I would get an error if the default wire or
logic type is used as an array, structure, interface, etc., forcing me to
explicitly declare those types.
I could support this but it still means a mixture of both logics and wires
in an interface that permits a bi-directional data bus.
> - Outside a module, at the module instance, I can explicitly declare
everything a logic.
Permitted either way - with or without passage of my proposal.
> - Outside a module, at the module instance, undeclared signals will
default to a wire, following existing Verilog-2001 rules.
Same as today. I'm okay with this.
> Your notes suggested that a proposal was made to replace "logic" with an
expanded "reg", so that the reg can do everything an SV 3.0 logic can
do. I'm fine with that. I cannot think of any place expanding the allowed
usage of reg would cause a backward compatibility problem. Yes, the term
"reg" has confused new Verilog users for years, but we've all survived the
ordeal. I find expanding the legal usage of reg types, but keeping the
true variable behavior, to more user friendly and intuitive than your
proposal of expanding the legal usage of wire AND giving it a
schizophrenic, context-sensitive dual behavior.
So now you have an interface with all variables declared to be of type reg
instead of wire (assuming that logic does not exist). I don't think this is
user friendly at all even if we have survived the ordeal up until now.
> I like changing "logic" to "ulogic" and "bit" to "ubit". In part, it
helps make it clear that these are unresolved data types. Mostly, I like
the change, because it does not reserve keywords that are likely to show up
in existing Verilog models.
Agreed.
> To summarize, I support your campaign to reduce the number of required
declarations in a module, but I do not support making wire a dual-behavior
data type. Nor do I support making any other data type have context
sensitive behavior. I prefer that wire be inferred following Verilog
rules, and SV add new rules for inferring reg or logic variables. I'm OK
with expanding the legal usage of reg and eliminating logic, as long as
rules require single driver usage, within and without a module. I'm also
OK with keeping logic, with those same restrictions. I like renaming logic
and bit to ulogic and ubit.
>
> Keep up the campaign, and hopefully we can strike a compromise that
reduces necessary declarations, without radical changes to either Verilog
or SystemVerilog 3.0.
>
> You asked for my opinion...
I did! :-(
>
> Stu
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 : Tue Jan 28 2003 - 12:09:15 PST