RE: [sv-bc] const vs. constant in SV (Was: Data-Types: status of "var" proposal)

Greg and Jonathan,

const and constant mean different things in SystemVerilog.

In Verilog and in SV, a constant are values that can be computed at
elaboration time. (Excuse me for not being more precise)

A const is a variable that is computed during the initialization phase
of the scope it is declared in. A static const will be initialized
before time 0, and an automatic const will be initialized when its block
is activated.

The main advantage of a static const variable over a parameter constant
is that it can be initialized with things like hierarchical references
to parameters, something that is not allowed in constant expressions.

Dave

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Greg
Jaxon
Sent: Friday, November 19, 2004 10:58 AM
To: Bradford Jonathan
Cc: btf-dtype@boyd.com; sv-bc@eda.org
Subject: Re: [sv-bc] DataTypes: status of "var" proposal

Jonathon,

    In C++ there are good reasons to offer const variables. I don't
see where SystemVerilog (without a pointer type) needs this. But it
probably does not hurt and it may help C interoperability.

    The issue I wonder about more is whether there is a good semantics
for constant nets - is there a "const wire logic [1:0] hotntot =
2'b10;"?

    I'm also unclear on what is/has been/will be proposed regarding
const
functions (or more precisely functions returning const objects). These
issues of orthogonal integration with the rest of the language require
seeing
a coherent proposal to judge.

Greg

Bradford Jonathan wrote:
> Hello
>
> There was some discussion about the ordering of statements in the var
statement,
> i.e. const / var / automatic / rand ... etc.
>
> An example was
>
> const var logic myVar;
>
> On retrospect for this case, what is 'const var' declaration. A
constant function
> and a constant argument is necessary, but a constant variable sounds
contradictory.
>
> Shouldn't const be a basic entity like parameter, as opposed to a
variable declaration
> attribute ?
>
> var logic myVar;
> parameter logic myParam;
> const logic myConst;
>
>
> Regards
>
> Jonathan Bradford
>
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of
Kathy
> McKinley
> Sent: Friday, 19 November, 2004 5:44 AM
> To: btf-dtype@boyd.com; sv-bc@eda.org
> Subject: [sv-bc] DataTypes: status of "var" proposal
>
>
> Hello everyone,
>
> Based on the subgroup meeting today, I am supposed to make a
procedural
> recommendation for the "var" aspect of our proposal. So, here goes.
>
> The "var" proposal is coming along beautifully, but it is not ready
> to be folded into the rest of the "data types on nets" proposal.
> In particular, changes to section 18 are required, and we do not
> have sufficient feedback on the proposed changes.
>
> This extension clearly has a lot of support, and there is active
> positive feedback (with no negative feedback) on the latest grammar
> proposals and the section 5 wording proposal (as long as the examples
> are enhanced). The more limited feedback on proposed changes to
section
> 18 is positive as well. I propose the following course of action:
>
> We will include a separate section at the end of the "data types
> on nets" proposal. It will include the following:
>
> - Brad's latest grammar proposal
>
> - Kathy's latest addition to section 5, plus Steven's
> recommended example enhancements
>
> - Steven's latest modifications to section 18
>
> We will *not* propose changes to the typedef syntax/semantics
> (e.g. "typedef foo [7:0];").
>
> This will allow the SV-BC to vote on data types on nets without
> the additional "var" enhancement. However, if the SV-BC chooses,
> it can vote on this extra section too. Or, it can provide feedback
> for another revision.
>
> Please let me know what you think. In the absence of negative
feedback,
> I will fold the "var" proposals as described above into an "optional"
> section of the document for distribution on Friday.
>
> Kathy
>
>
Received on Fri Nov 19 15:17:32 2004