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 10:56:56 2004