Subject: Re: $sv-ec Logic Data Types need fixing
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Wed Nov 27 2002 - 12:06:08 PST
Hi, All -
Stu, Kev and Dave Rich have all given good feedback. I would like to
respond to all of their comments in this one email response since some of
their points are overlapping.
At 06:13 PM 11/26/02 -0800, Stuart Sutherland wrote:
>Cliff,
>
>Your PDF file proposes:
>
>Proposal #1 - remove the restriction described in feature #5. Allow
multiple driver-assignments to logic
>types.
>Proposal #2 - make the "logic" the default data type of SystemVerilog.
This is possible and desirable if
>Proposal #1 passes. All existing Verilog models would work if proposals
#1 and #2 pass.
>
>I am not disagreeing with your concept of your proposals, but I do think
your proposals will defeat an important aspect of the logic data type,
which I feel is a major advantage. By being restricted to a single driver,
the logic type does not have the simulation overhead of either strengths or
multi-driver resolution. I see this limitation as an important means to
improve simulation run-time performance.
>
>Your proposals do not state what multi-driver resolution function the
logic type should have. Do you want the logic type to behave as a wire, a
wand, a wor, a tri1, a tri0, a trireg, or something totally new?
Good point. I want wire-type behavior. We can also prohibit declaring logic
types with strengths. I believe the point of performance is not a big issue
for the following reasons:
(1) I estimate that 90%+ of all assignments are single-driver,
non-strength assignments. Clever vendors will compile these as efficient
4-state, non-strength, logic types.
(2) I estimate that up to 9% of all assignments are multi-driver
assignments without strength. This includes almost all bi-directional
signals and inout ports both within designs or inout ports on designs that
interact with a testbench. These can be treated as 4-state wires without
strength information.
(3) The remaining 1% of designs involve board design, gate-level design
with strengths, or bi-directional busses with weak-keepers. These would
have to be treated as 4-state wires with strength.
The clear optimization guideline is to avoid strengths to improve
simulation efficiency. If I remember correctly (that's pretty iffy
;-) from a VCS update presentation, VCS optimizes away strength
information from designs wherever possible to improve simulation
efficiency. This is a vendor competitive-advantage issue. The hard part is
making the decisions at compile time (not that hard), as opposed to forcing
engineers to think more about their data types when coding. The latter was
one of my big complaints about VHDL.
The trade-off is a few more seconds of decision time during compile versus
minutes to hours to get it right by RTL coders.
>No matter what net data type you pick for the logic type to imitate, I
don't like it. It means each and every bit of the logic type will require
16 bits of virtual memory to simulate, and have all the overhead of
existing net data types.
I disagree. A smart compiler recognizes designs that do not have strengths
and eliminates the need for the 16-bit storage per bit. I believe VCS
already makes this optimization.
>I like having a data type that only permits a single driver, and gives me
the optimizations that can go with that. SystemVerilog is addressing the
needs of high-level abstraction, where multiple drivers are seldom needed.
Seldom needed is very debatable. Most RAM devices have bi-directional data
buses. Many ASIC devices have bi-directional data buses. High-fanin onehot
muxes have multiple drivers. Bus crossbars have multiple drivers (Paul
Zimmer of Cisco is going to give a paper at SNUG where one of the examples
is a switching crossbar with 1,000 drivers driving an entire switch
fabric). Any testbench that interacts with a model with an inout port is a
multi-driver problem.
This was one of my complaints about doing ASIC design with VHDL. You first
had to decide if you were going to use std_logic, which permits multiple
drivers on the same signal but typically required resolution functions to
perform even the simplest arithmetic operations, or if you were going to
use std_ulogic, which permitted more arithmetic operations and interaction
with the integer type but did not resolve multiple drivers without a
resolution function. As far as I can tell, the VHDL camp is split on which
is preferred for ASIC design. The logic type in its current form is going
to cause a similar split in the Verilog camp.
>By the way, I disagree with one statement in your document, but it has
nothing to do with your primary concern:
>
> "3. A variable of type logic does not permit assignments from more
than one procedural block - This is good!"
>
>I can find nothing in the LRM that states this, and SystemSim allows
multiple procedures to write to the same logic variable. The logic type is
restricted to a single driver OR any number of procedural assignments from
any number of procedures. It is the always_comb and always_latch
procedures that add the restriction of a single procedure assigning to a
variable.
Oops! I think you're right. This was probably just wishful thinking on my
part. I guess I was hoping that the new logic data type would expose this
common blunder as a syntax error. Some of the supporting arguments for
limiting drivers on the logic type are to help avoid multi-driver mistakes
by RTL coders. My opinion based on experience is that this is a rare
problem. On the other hand, people making assignments to the same variable
from multiple procedural blocks is a common and nasty problem to debug.
This would be a worthy restriction to help users avoid mistakes, but I can
live with not having this restriction (**small amount of sobbing!**)
>Stu
At 12:31 AM 11/27/02 -0800, Kev wrote:
>> From: Stuart Sutherland <stuart@sutherland-hdl.com>
>>
>> Cliff,
>...
>> Your proposals do not state what multi-driver resolution function the
logic
>> type should have. Do you want the logic type to behave as a wire, a wand,
>> a wor, a tri1, a tri0, a trireg, or something totally new?
>
>I got the impression Cliff just wants those assignments to work like any
>others (last one sticks, no resolution).
Actually I do want multi-driver resolution and I want the type to be type
wire (the same as multiple continuous assignments driving the same wire)
but I have very little problem prohibiting strengths from being used with
the logic type.
Now that I think about it, I guess there is a small problem with making a
strength-less "logic" the default type. The problem is that there are some
board designs that have gate-primitives with strengths that drive implicit
nets with pullup resistors (frequently a second driver through an rtran
type of device) that could fail if logic becomes the default. There are
also ASIC designs with bi-directional nets and busses with instantiated
weak-keepers (sometimes called bussus - bus-sustain) devices that hold a
value at a weak 1 or 0 when the bus is not otherwise driven, to keep CMOS
devices from either consuming excess power or burning up.
There are two potential solutions to this problem:
(1) make the user deal with it by adding `default_nettype wire
(2) make logic the default type unless it is connected to an continuous
assignment with strengths, gate with strengths, or strength-reducing switch
primitive.
I prefer option (2). I want a smart tool, not more to think about and teach
(even though this could bring me more teaching business ;-)
>My problem with "logic" is not the data type, but the whole concept of
passing
>variables through ports. Up to now Verilog has been as much a hardware
description
>language as a hardware design language, most of the connections between
modules
>map to physical wires and the driver/resolution semantics try to model
how those
>wires will behave. I'm not sure how "logic" fits into that, if you are
not going
>to do resolution there's not much point in bothering with the Xs and Zs,
you might
>as well just use 2-state signals.
Thanks, Kev, for bringing this up. I had forgotten about this capability.
I tend to agree with Kev on this point. Dave brought up that he thought 99%
of all nets are only driven by a single source. Based on my own design and
consulting experience, I believe Dave is quite incorrect in this assumption
(explanation and details later).
On the other hand, I believe that 99.9% of all assignments do not want an
instantiated module to make a "last-assignment-wins" update to a variable
at a higher level of hierarchy in a design. This is generally a bad coding
style within a module, so I have a hard time believing that this is a
desirable coding style through module indirection at a higher level.
Does Dave have a good example of where this is useful or used by existing
Superlog customers?
It seems that this "feature" is going to be difficult for tool vendors to
check because now a vendor is going to have to descend instantiated modules
whenever a logic variable connects ports from two or more instantiated
modules, just to see if one of the logic ports was driven by a continuous
assignment or gate, to insure that there are not multiple drivers at the
higher level.
>I don't think the semantics of passing variables through ports are good for
>describing re-usable modules, mixed-signal or back-annotated design flows, so
>I would be happy to see more restrictions rather than less.
>
>Kev.
At 11:54 PM 11/26/02 -0800, Dave Rich wrote:
>Nice try Cliff!!
"Nice try Cliff!!" ??? Does it look like I was trying to make a joke or
pull a fast-one on the committee??
>Let me try to separate your proposal into some manageable chunks.
>
>1. interfaces and logic are completely independent of each other. How do
you feel they are related?
The logic type is almost required with interfaces. I generally cannot use
the wire type with an interface because one of the connections usually ties
back to a procedural assignment, which requires a variable type. I
generally cannot use a variable type with an interface because one of the
connections usually ties to an input somewhere, which requires a net type.
So I am left with the logic type to make connections at both ends, unless
the connection is a bi-directional (multiply driven) port, where I will
have to use the wire type declaration. If I have not completed the RTL
coding of the sub-blocks, the compiler will not report errors from multiple
drivers until all of the sub-blocks are done. This debugging cannot be
accomplished until later (one of the problems I ran into with
interface-based design - the design compiled way too easily, only to show
errors as I started adding the sub-block RTL code - quite top-down-design
user unfriendly).
If logic were my universal data type that permitted multiple drivers, I
could use logic everywhere in an interface and in new Verilog designs. That
was the tie-in.
>2. reg is obsoleted by logic.
Correction - reg should have been obsoleted by logic, but, as Kev reminded
me above, regs and variables connected to output ports basically turn into
continuous assignments external to the module, whereas the logic type gives
last-assignment-wins behavior outside of the module, which behaves like no
hardware I have ever designed. When was the last time you put two ASICs on
a board, connected two outputs (enabled at different times) and saw
last-assignment-wins behavior if they were both incorrectly enabled at the
same time? Anybody who misses this bug due to the non-hardware behavior of
the logic type is going to see smoke when the actual board is powered up.
>We could have just extended the functionality of reg to behave like other
SV variables and still have been 100% backward compatible. However people
(like yourself) thought this was too dramatic a change; people would get
lost if they didn't get their dosage of "illegal left-hand-side assignment"
error messages.
I'm not sure what you are referring to here "(like yourself)." When many of
us first saw the logic type, we hailed it as the universal type that would
keep us from ever having to see the error message you described above. When
we discovered that logic prohibited multiple drivers, we quickly figured
out that it could not become the default type (much to our disappointment)
because it would break existing models. If you mean extending reg to have
the same behavior as logic, I have given a reason why that would break
existing designs in real hardware (above). Would you like to further
qualify my "too dramatic" reaction described above? What am I missing?
>So logic was created to distance itself from the legacy "reg" behavior.
Moving forward, there is no longer a reason to teach people about reg.
Perhaps you should propose that we remove logic and eliminate the original
restrictions on reg.
What restrictions need to be removed?
>3. The current spec does not rule out the possibility of removing the
single driver restriction at a later time. This will also require strength
resolution in logic,
But the current spec allows a behavior (last-assignment-wins outside of the
scope where assignments take place) that I consider to be quite dangerous
and inconsistent with real hardware behavior. Do you have a good example
(your own or a customer example) that clearly demonstrates the value of
this behavior?
>4. I think your #2 proposal is good even without allowing multiple
drivers. Over 99% of all signals do not have multiple drivers and do not
require strength resolution. This would force people to declare nets with
multiple drivers, which I think is a good thing. Again, I don't see
anything we are doing now that would rule this out later.
Again, based on design and consulting experience, I think your estimate is
wrong. I believe up to 10% of assignments are either to bi-directional
buses (which typically involve multiple drivers) use onehot muxes, use
crossbar multiple assignments or involve instantiated bussus or pullup
devices. Testbenches interacting with inout ports usually employ multiple
drivers. RAM devices frequently have bi-directional data ports. Some Xilinx
devices have tbufs (high-drive internal tristate drivers) to drive long
lines within FPGA devices.
I just think your estimate of 99% is wrong. I can think of too many design
or testbench examples where multiple drivers were part of the code.
>Dave
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 : Wed Nov 27 2002 - 12:06:40 PST