Subject: Re: $sv-ec Logic Data Types need fixing
From: sv-xx@grfx.com
Date: Wed Nov 27 2002 - 00:31:56 PST
> From: Stuart Sutherland <stuart@sutherland-hdl.com>
>
> 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?
I got the impression Cliff just wants those assignments to work like any
others (last one sticks, no resolution).
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.
I don't think the semantics of passing variables through ports are good for
describing re-usable modules, mixed-signal or back-nnotated design flows, so
I would be happy to see more restrictions rather than less.
Kev.
> 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 : Wed Nov 27 2002 - 00:33:30 PST