Subject: Re: [sv-ec] Errata for section 5
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Mon Sep 08 2003 - 13:28:21 PDT
Jamie,
My comments are interspersed below.
Arturo
----- Original Message -----
From: "LaFlamme, Jamie" <jamiel@Model.com>
To: <sv-ec@eda.org>
Sent: Monday, September 08, 2003 10:07 AM
Subject: [sv-ec] Errata for section 5
> I found what I believe are a number of inconsistencies and possible
> errors in section 5 of the LRM. As far as I know none of these
> are listed in the current errata working document:
>
> o Section 5.1 contains the statement "A variable can be static
> (storage allocated on instantiation and never de-allocated)
> or automatic (stack storage allocated on entry to a task,
> function or named block and de-allocated on exit)." -
> automatic variables can also be allocated in unnamed blocks
> so the word "named" should be removed.
Yes!
> o Section 5.1 should include genvars in the list of constants
> supported in Verilog 2001.
Yes.
> o Section 5.1 includes the statement "C constants are either
> literals, macros or enumerations. There is also a const,
> keyword but it is not enforced in C." It seems like this
> entire paragraph should be removed, but the second sentence
> is untrue according to the ANSI C standard and several
> compiler implementations so at a minimum it should be removed.
I Agree.
> o The BNF for block_variable_declaration in section 5.2
> contains a required "lifetime" component that should be
> optional.
Yes.
> o When multiple variables are declared within a single
> statement, the BNF in 5.2 requires all variables in the
> statement to be initialized or none of them. For example,
> the following appears to be illegal:
>
> int a, b=0;
>
> Is there a reason to not allow initialized and non-
> initialized variable declarations together? This is
> true for block_variable_declaration and for
> list_of_variable_identifiers_or_assignments.
I believe this is a BNF error. Any mix of initialized and non-initialized
variables should be allowed.
> o In section 5.3 there is a brief discussion about the meaning
> of a const class object. If a class object is going to
> be treated as const then it seems like it should be possible
> to declare class methods as "const" otherwise there is
> no way to determine if a method can be called for a const
> class object.
When a class handle is declared as const, it means that the handle itself
may not overwritten. That is unrelated to what methods are allowed on
that class.
> o Section 5.4 includes both of the following seemingly
> contradictory statements:
>
> - "A variable can be declared with an initializer, which
> must be a constant expression."
> - "Initial values in SystemVerilog are not constrained to
> simple constants; they can include run-time expressions,..."
>
Yes. I believe we already have an errate for that item.
> o Section 5.5 contains the statement "If an initializer is
> used, the keyword *static* must be specified to make the
> code clearer." Should this say that either *static* OR
> *automatic* must be specified?
I don't understand why this is necessary.
> o Near the end of section 5.5 there is a restriction that
> "automatic or dynamic variables cannot be used to trigger an
> event expression...". This restriction does not exist in
> Verilog 2001 for automatic variables and it is valid to have
> forks within an automatic task where one forked process
> triggers another process based on a local variable.
Yes. I believe this is part of the discussion being held in EC regarding
implicit copy-on-fork semantics of automatic variables, etc...
When those issues are settled, we should reconcile this paragrph as well.
I think the intent of that paragraph was to disallow hierarchical references
to trigger events to automatic variables.
> o The BNF in section 5.2 seems to allow variables to have a
> lifetime of "automatic" anywhere that a variable can be
> declared, including at module scope. I didn't see anywhere
> that explicitly says this is illegal to do except that
> section 5.5 indicates "data declared inside a module or
> interface but outside a task, process or function is local
> in scope and static in lifetime". It would be nice if
> automatic variables outside of tasks, functions and blocks
> were explicitly made illegal.
Yes. This should be a BNF errata.
>
> Sorry if I inadvertently repeated an issue that has already been
> addressed.
>
> -Jamie LaFlamme
>
This archive was generated by hypermail 2b28 : Mon Sep 08 2003 - 13:28:42 PDT