Subject: Re: $sv-ec Logic Data Types need fixing
From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Tue Nov 26 2002 - 18:13:48 PST
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?
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 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. Why pay a significant memory
usage and performance penalty when I don't need it? Even at the gate
level, synthesized designs will have very few cases of multiple drivers,
and the logic data type, with its current single-driver limitation, will
continue to work just fine. On those infrequent cases where multiple
drivers are needed, I still have the expensive net data types available.
I'm still on your side, Cliff. I do like the idea you are putting forth of
a truly universal data type. It would greatly simplify life with
Verilog. If those that implement simulators can convince me that we can
have our cake and eat it too--that is, that the logic data type can be
automagically optimized when there is only a single driver, and keep
multi-driver resolution only when needed--then I am in favor of your two
proposals. Perhaps it is possible the logic data type to have wire-like
multi-driver resolution for the logic type, without the expense of 16 bits
of strengths. Basically, a 4-state wire with no strengths.
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.
Stu
At 04:50 PM 11/26/2002, Clifford E. Cummings wrote:
>Hi, All -
>
>Attached is an analysis of, and a proposal to fix the SystemVerilog 3.0
>"logic" data type. I'm not sure which committee should take this up. It is
>both a fix and an enhancement.
>
>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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland-hdl.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland-hdl.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Tue Nov 26 2002 - 18:17:29 PST