Re: [sv-dc] Type confusion

Hi Kevin.

Verilog "reg" vs. "wire" declarations really don't have to be
cast in the stereotype of "type declarations" or otherwise.

They are what they are, functional attributes of a variable.

A wire is nonlocalized; it is a connection object generally
with two or more localized endpoints. The endpoints
are localized ports, pins, or procedural variables. I agree
with what I assume is your view that in an A/MS context, a
plain wire should be considered to have no specific type.

A reg is localized, and, as such, may be used procedurally to
store a value between successive procedural assignments.

I also agree that one should be able to type the drivers to a
wire or reg by declaring it as "reg logic a, b, c;" or
"wire voltage d, e, f;", etc.

I like the idea of not permitting a dangling declaration of
"logic a, b, c;", because of the ambiguity you point out.

Many, maybe most, of the SV enhancements have been attempts at
providing quick and dirty convenience for specific users,
rather than supplying the structured, simple, well-architected
language which SV really should become.

It would be a great improvement to partition the current SV
1800 Std document so that its myriad functionalities were
organized into easily comprehended (and thus readily
adopted) subcategories. This has been a good plan for 1076,
in my opinion. 1800.1 (=verilog), 1800.2 (=verilog+assertions),
etc. . . .. By limiting the scope of each subcategory, it should
be possible to simplify or at least clarify everything in that
scope.

Maybe this will be possible after the current ambiguities and
other bugs have been removed?

Kevin Cameron <dkc@grfx.com> wrote:
> Gecko/20100520 SUSE/3.0.5 Thunderbird/3.0.5
> MIME-Version: 1.0
> To: sv-dc@eda.org
> Subject: [sv-dc] Type confusion
> References: <4C3DFAB2.1010404@model.com> <4C4E4C23.7010703@v-ms.com>
> <4C4E4ED4.9000000@model.com> <4C4E847F.7050706@v-ms.com>
> <4C4EE868.1000402@model.com> <4C4F2402.2010908@v-ms.com>
> <C171323BB93CB94897E300CBB6D4537F255A70C4@CLMSG-01.ad.cirrus.com>
> <4C505F7B.90908@v-ms.com>
> In-Reply-To: <4C505F7B.90908@v-ms.com>
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> X-EDA-MailScanner-Information: Please contact the ISP for more
> information
> X-EDA-MailScanner-ID: o6SN0pvE015988
> X-EDA-MailScanner: Found to be clean
> X-EDA-MailScanner-From: dkc@grfx.com
> X-Spam-Status: No
> Sender: owner-sv-dc@eda.org
> Precedence: bulk
>
>
> IMO the Verilog-LRM(s) don't really reflect what is/has a type properly.
> A number of things in Verilog are implicit and are confusing to casual
> users.
>
> A typical case is that of "wire" and "reg", which really declare
> semantic objects rather being type declarations - the type being
> implicit. What the "wire" declaration does is create in the local scope
> a connection point for drivers and receivers which maps to a physical
> wire in the design (Verilog originally being a gate level simulator).
> The "reg" declaration does the same thing but adds a local driver with
> the (default) type "logic" which can be used in behavioral code. So
> when you say -
>
> reg foo;
> always @(reset) foo = 0;
> always @(clock) foo = !foo;
>
> - a wire is created for "foo", a driver of type "logic" for it, and the
> assignments to foo actually goes through the driver. Connections through
> ports to other modules only deal with the "wire" part of foo. Signal
> resolution looks at all the drivers attached to the wire.
>
> Since you can determine from usage that "foo" needs a driver, the reg is
> somewhat redundant, it was probably only there to make parsing easier in
> the original tools. So SV allows the use of "logic" instead of "reg",
> but that creates some ambiguity since what you end up with depends on
> usage (instead of just the declaration).
>
> For me the logical extension of the language is to say that you can use
> explicit types with the existing declarations, i.e.
>
> wire w;
> reg x;
>
> Can be replaced with (and is equivalent to) -
>
> wire logic w;
> reg logic x;
>
> For a real-valued net -
>
> wire real w;
> reg real x;
>
> - the underlying wire has no type, but in the local context and drivers
> attached to will have type real. If you want a resolved type you then do
> something like:
>
> class res_real : extends Signal #(real); // Signal is a built-in
> template
> function real resolver(real values[]);
> ...
> endfunction
> endclass;
>
> reg my_real x;
>
> In this case the fact that my_real is built on the Signal template means
> you can discard the "reg" and determine if you need a driver from usage.
> A class based on the Signal template has "primitive" semantics (as in
> Gord's proposal).
>
> In a similar vein "assign w = 1" is the same as "assign logic w = 1",
> and you can reuse the syntax with other types - e.g.:
>
> assign real vdd = 1.5; // creates wire with single driver of
> unresolved type "real"
> assign real vss = 0.0;
>
>
>
> Backward compatible, no new keywords.
>
> Notes:
>
> You might want to use the "reg" syntax to create a driver to be used
> from DPI code when SV usage won't create one.
>
> Net types like "wor" etc. are just a shorthand for saying create a wire
> and the (locally) attached driver obeys wired-or resolution rules, i.e.
> a "net type" is really a "resolution rule" for driver being declared.
>

-- 
      John Michael Williams
      Senior Adjunct Faculty
Silicon Valley Technical Institute
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.