Subject: RE: [Fwd: [sv-bc] Removal of the SystemVerilog logic data type]
From: Jay Lawrence (lawrence@cadence.com)
Date: Fri Jan 24 2003 - 16:24:15 PST
Let me explain why I believe logic should probably still be kept even
though our straw poll agreed that reg and logic are really identical.
A declaration such as:
struct packed {
integer j;
reg [7:0] r;
}
Is misleading. It looks like a reg is an object here. In particular
while reviewing SV 3.0 inside of Cadence we had people expecting to be
able to write.
struct packed {
wire w;
reg [7:0] r;
}
This is illegal because a wire can not be in a struct.
If we only allow reg to be used where an object is being declared, and
logic where a type name is being used it would make things clearer.
The extension I would really like, but is probably beyond scope is
something like:
typedef struct packed {
integer j;
logic l;
} my_struct;
reg my_struct rs;
wire my_struct ws;
Although other data types, like integer, have the same issue you can
imagine them as typedefs instead of predefined keywords.
typedef signed [31:0] logic integer;
typedef signed [31:0] bit int;
Then
reg integer ir;
wire int ir;
Would be legal. For backward compatibility you allow the reg to be
optional. So that the old:
integer ir;
And
reg integer ir;
Are exactly the same.
If we don't allow reg inside struct definitions now, we may be able to
consider this extension later without backward compatibility problems.
Jay
P.S. The issue of an object declaration that can automatically morph
between variable and net semantics is different that the discussion of
reg vs. logic. To solve this problem a new kind of declaration
altogether (variable, net, morphvar) would have to come into existance.
===================================
Jay Lawrence
Architect - Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
> -----Original Message-----
> From: Stefen Boyd [mailto:stefen@boyd.com]
> Sent: Friday, January 24, 2003 7:08 PM
> To: sv-bc@eda.org
> Subject: Re: [Fwd: [sv-bc] Removal of the SystemVerilog logic
> data type]
>
>
> At 03:23 PM 1/24/2003 -0800, Stuart Sutherland wrote:
> >Perhaps calling logic a "universal" data type is too
> general, but keep in
> >mind that SV 3.0 makes logic the default type for most
> >circumstances. That makes it pretty close to universal, if
> not completely
> >universal. In fact, in the few places that SV 3.0 says the
> default data
> >type is something other than logic, I have noticed the
> SystemSim Superlog
> >simulator still defaults to logic, further proving the
> potential of logic
> >being a universal data type. The last-write-wins behavior for wired
> >outputs may not be the best representation of hardware, but
> syntactically,
> >logic can truly be used almost universally.
>
> If we do move to using var to get the shared variable behavior
> in 3.1 versus the shared behavior we got by default for all the
> new types added in 3.0, the possibility of logic as a truely
> "universal" data type is reopened.
>
> The strongest argument that killed my universal type proposal
> for logic was that all the new types allowed shared variable
> behavior, so making an exception for logic would be a strange
> exception.
>
> What I had proposed for logic was:
> 1) Allow it to be driven by procedural blocks (i.e.
> always, initial)
> *or* drivers (i.e. cont assigns, module inst
> outputs, gate outputs)
> 2) If both procedural assignment and driver, then
> error (nothing new
> so far)
> 3) If there are multiple drivers, use net resolution
> (treat it like a
> wire)
>
> If the bc decides to use explicitly shared variable behavior using
> var instead of the 3.0 implicitly shared variable behavior, I would
> love to see the reconsideration of having a logic type that could
> morph itself into a truly universal type. That would make the
> retention
> of this keyword worthwhile. Otherwise reg and logic are almost
> identical (assuming *explicit* shared variable behavior).
>
> Eliminating logic by allowing reg to take on ability to be used
> with a single driving statement (such as cont assign) would be ok,
> but retaining logic and making it truly universal would be extreemly
> valuable (but this would seem to hinge on the BC going to explicitly
> shared variables).
>
> Stefen
>
>
> --------------------
> Stefen Boyd Boyd Technology, Inc.
> stefen@BoydTechInc.com (408)739-BOYD
> www.BoydTechInc.com (408)739-1402 (fax)
>
>
This archive was generated by hypermail 2b28 : Fri Jan 24 2003 - 16:24:44 PST