Subject: Re: Logic Data Type Proposals - 20021209
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Dec 10 2002 - 16:13:09 PST
> From owner-sv-bc@server.eda.org Tue Dec 10 00:31:44 2002
> From: "Dave Rich" <David.Rich@synopsys.com>
>
> Cliff,
>
> Here's yet another approach. What about having a default nettype that
> automatically chooses between wire and logic. You want the tool to
> decide between two different data types, not one data type with two
> different modes
>
> If one of your criteria is not to break existing Verilog designs, then
> 'logic' will never fully replace 'wire'. The BC committee has decided
> that force/release on a logic variable behaves like a reg, not a wire
> (i.e.a release will not return the logic variable to the currently
> driven value). Also, MOS primitives propagate the strength of their
> inputs in order to determine the strength of their outputs. And many of
> those cases have only one driver as the input to a MOS primitive.
I'd just like to say that from a mixed-signal perspective "wire" is exactly
that - the interconnect between drivers (e.g. transistors) and receivers
(other transistors etc.). "reg" creates digital driver of type logic for
a wire/net, but in mixed-signal the wire itself has no type. A wire can
have multiple drivers of different types as long as there is a resolution
function that handles them.
"logic" declarations appear to be just variable declarations and passing
them through ports does not seem to turn them into wires. If I wanted to
use that type of object with an AMS simulator I would have to consider
it as a singly driven wire with the driver in the context where it is
declared, otherwise it isn't possible insert a digital-to-analog conversion
module to bridge the value into analog.
I would suggest defining the semantics of variables passed through ports
as being the same as singly-driven wires, otherwise I have to tell the
mixed-signal engineers they can't use "logic" and "bit" through ports
because it will break plug-and-play reuse.
Kev.
> I also wanted to reiterate that I believe the SystemVerilog spec should
> have been clarified such that it is illegal to connect two or more
> module output ports together where variable sharing occurs. You are
> essentially creating a multiply driven signal if the port directions are
> to be adhered to. This was my action item from the F2F meeting.
>
> Dave
>
>
> Clifford E. Cummings wrote:
>
> > Hi, All -
> >
> > The attached document proposes the following:
> > - allow logic to have multiple drivers (same with bit, real,
> > struct and int).
> > - do not permit last-assignment wins behavior outside of the
> > current scope.
> > - (assuming the above two conditions) make logic the default
> > type for SystemVerilog
> > - add a new type called ulogic (unresolved logic) that does the
> > exact same thing as logic but prohibits multiple drivers - OR - a new
> > option: `default_nettype unresolved (the second alternative means that
> > we would not need new keywords: ulogic, ubit, ureal, ustruct, uint).
> > - Define resolution tables for each of the new types.
> > - Add a new compiler directive: `default_resolution bit 0 (or 1)
> > - Possibly add user-defined default resolution capability for
> > real, struct and int, with permitted legal values
> >
> > 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
>
>
> --
> --
> Dave Rich
> Principal Engineer, CAE, VTG
> Tel: 650-584-4026
> Cell: 510-589-2625
> DaveR@Synopsys.com
>
>
>
>
This archive was generated by hypermail 2b28 : Tue Dec 10 2002 - 16:14:33 PST