{Disarmed} Re: [sv-ac] Email ballot result (Due May 11 and May 16 )

Manisha,
*Change*
Multiple assertion_type values can be specified at a time by OR-ing
different values.* E.g. *a task with assertion_type value of 3 (which is
same as Concurrent|Simple_Immediate) shall apply to concurrent and simple
immediate assertions. If assertion_type is not specified, then it defaults
to 15

*To: *
Multiple assertion_type values can be specified at a time by OR-ing
different values. For example, a task with assertion_type value of 3 (which
is same as Concurrent|Simple_Immediate) shall apply to concurrent and simple
immediate assertions. If assertion_type is not specified, then it defaults
to 15

*[Ben] I don't think it is correct to start a sentence with "E.G. *
*The Lrm does not do that. BTW, e.g., has a comma. The LRM is mostly
consistent with the comma, but on occasions, does not have the comma. *
*-----------------------*
*From: *
The effect of the $assertcontrol system task is determined by the value of
its first argument control_type which shall be an integer expression

*To: *
The effect of the $assertcontrol system task is determined by the value of
its first argument control_type, which shall be an integer expression
*[Ben] Need a comma before the which. *
*------------------------------*
By default, the fail action is executed. This task also affects the
execution of default fail action block.
[Ben] *What does that mean? What is the default fail action block? You
already say that the fail action block is executed. *
*?? *
*-----------------------*
*-----------------------------*
*Ben Cohen *
*
*
On Wed, May 18, 2011 at 3:16 AM, Kulshrestha, Manisha <
Manisha_Kulshrestha@mentor.com> wrote:

> Hi,
>
> I have uploaded the updated version for 3295 based on feedback in this
> email. Anupam, Erik, Jacob, please review.
>
> Dimitry, do I need to update the proposal based on draft1 ? Same section is
> modified in draft1.
>
> Manisha
>
> ------------------------------
> *From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of *Korchemny,
> Dmitry
> *Sent:* Tuesday, May 17, 2011 3:26 PM
>
> *To:* 'sv-ac@eda-stds.org'
> *Subject:* [sv-ac] Email ballot result (Due May 11 and May 16 )
>
> Below are the results of the email ballot:
>
>
>
> 3069 3213 3385 3295
>
> Yes Yes Ashok Bhatt
>
> Yes Yes Yes Yes Laurence Bisht
>
> Yes No Yes Yes Eduard Cerny
>
> Tapan Kapoor
>
> Yes Yes Jacob Katz
>
> Yes No Yes Yes Scott Little
>
> Yes No Yes Yes Manisha Kulshrestha
>
> No No Yes Yes Anupam Prabhakar
>
> Yes Yes Yes Yes Erik Seligman
>
> Samik Sengupta
>
> Yes Yes Tom Thatcher
>
>
>
> Issue 3295 and 3385 passed with friendly amendments.
>
> Issues 3069 and 3213 failed.
>
>
>
> Comments:
>
>
>
> *Jacob:*
>
> 3295
>
> Add an empty line between the items in the list describing the control_type
> values, like it is done in the list of $assertcontrol arguments
>
>
>
> *Tom:*
>
> 3069
>
> Change "Global clocking may be declared" to "A global clocking block may be
> declared"
>
>
>
> *Anupam:*
>
> 3069
>
> The proposal says
>
> ‘a) Look for a global clocking declaration in the enclosing module,
> interface, checker or program instance scope, or a generate block therein.
> …..
>
> b) Look for a global clocking declaration in the parent
> module/interface/checker scope instance of the enclosing
> module/interface/checker/program instantiation, or a generate block therein.
> ….’
>
> As per these rules any global clock declared inside a generate should not
> apply to the parent module scope. However the example with a conditional
> generate pulls such a default clock to the parent module scope. I assume
> the functionality of this example is important and you intend to propose
> that a module (or a program/interface/checker) with elaborated generated can
> have only one global clock (which is also mentioned in your proposal). The
> rules a) and b) should be modified to reflect this. Note that this would
> also mean that a global clock declared inside a ‘for generate’ would result
> in an error most of the time.
>
>
>
> 3295
>
> // disable concurrent and immediate asserts and covers for
>
> // 20 time units. The following systask does not affect expect
>
> // statements as control type is Off.
>
> $assertcontrol(OFF); // using default values of all the
>
> // arguments after first argument
>
> The ‘… for 20 time units’ is confusing as this $assertcontrol statement has
> nothing to do with that. You probably should add ‘After 20 time units …’ at
> the beginning of the comment before the next $assertcontrol.
>
>
>
> 3213
>
> ‘Expressions in concurrent assertions, except for disable conditions (see
> 16.13), are sampled, as explained in 16.5.1.’
>
> I think this should read as
>
> ‘Expressions in concurrent assertions, except for disable conditions (see
> 16.13), use sampled values, as explained in 16.5.1.’
>
>
>
> This sounds confusing to me too
>
> ‘When sampled value functions refer a past or a future timestep, they
> always take the final sampled value from that timestep, namely, the sampled
> value of an expression evaluated in the Postpone region of that timestep.’
>
> Maybe it should read
>
> ‘….., they take the value of the expression evaluated in the Postponed
> region using sampled values’
>
>
>
> 3385
>
> In the example always_comb just has two deferred assert statements – does
> the expression in a deferred (or immediate) assert contribute to the
> sensitivity of always_comb ? If not then we should add ‘…’ to denote that
> there are other statements inside the always_comb which will cause
> always_comb to trigger.
>
>
>
> *Erik:*
>
> 3069
>
> Aren’t we now supposed to have a title line at the top of the PDF, stating
> which Mantis it’s for?
>
>
>
> 3295
>
> - 1st paragraph in 20.11: remove ‘the’ in ‘the expect
> statements’, and add ‘the’ before $assertcontrol in ‘The arguments for
> $assertcontrol system task…”
>
> - Directive_type bullet: capitalize I in ‘if’ at start of last
> sentence.
>
> - In the coding example, I think we should define ALL_DIRECTIVES
> and ALL_ASSERTS in terms of |s of the other symbols, rather than directly
> providing the ORed numbers 7 and 15.
>
>
>
> 3213
>
> - In 16.5.1, you use the phrase ‘concurrent context’ in one
> bullet—since we got rid of that, replace with ‘sampled value’.
>
> - In 16.9.3, include a reference to 16.5.1 when we define
> $sampled.
>
> - 16.15.16.1: “saves the sampled values of their const
> expressions” è “saves the sampled values of its const expressions”
>
>
>
> *Scott:*
>
> 3069
>
> I would prefer, “A clocking block may be declared as the global clocking
> for all or part”. The current wording seems awkward to me.
>
>
>
> In the description following the first example I would change the word
> “Similarly” to “Similar”
>
>
>
> 3213
>
> -In the introductory explanation at the top of page 2 there is still a
> reference to $concurrent.
>
>
>
> -In 16.5.1 the final sentence in the second item in the section is very
> awkward. Could it be reworded as: “For example, the sampled value at time 0
> of variable y of type logic is X.”?
>
>
>
> -In 16.5.1, the second bullet states, “The initial value of any other
> variable or net is the default value of the corresponding type…” Do you
> mean the initial sampled value? Then farther down in the enumerated list you
> state that the initial sampled value of an automatic or local variable is
> undefined. I believe the second statement is what you want, but I believe
> the first statement should be clarified. What are the implications of
> making initial sampled values undefined? Is it a simulator error if an
> assertion needs a sampled value of an automatic variable in the initial
> timestep? This feels to me like it is working against the basic principles
> of the proposal to allow a more free use of “nonstandard” variables
> throughout the assertions. Why not take the default type values instead of
> undefined?
>
>
>
> [Note: Ed seems to be concerned about this point as well. I am not sure it
> is adequately addressed at this point although I don’t have any particularly
> good ideas about how to improve the situation.] I understand why it is done,
> but I think the descriptions of the sampled value functions have become
> somewhat confusing for the common case (static variables). “$past returns
> the sampled value of expression1 from the Postponed region of a particular
> time step strictly prior to the one in which $past is evaluated.” For
> static variables the sampled value doesn’t change in a timestep, so where
> the sampled value is grabbed doesn’t matter. I am not sure that is obvious
> to the casual reader. In fact, I wonder if folks may misinterpret this to
> mean that variables are sampled in the Postponed region instead of that the
> sampled value is captured in the Postponed region. I would like to see the
> definition of the common case more clearly stated, but I am afraid this may
> clutter up the definitions.
>
>
>
> *Manisha:*
>
> 3069
>
> 1. Remove 'as if ' in the following sentence. Also, I would prefer if
> this sentence does not contain ", which flattens properties and sequences,
> and substitutes actual arguments to sequence, property and checker instances
> for their corresponding formal arguments".
>
> When $global_clock is used in a sequence declaration, a property
> declaration, or as an actual argument to a named sequence instance, a named
> property instance, or a checker instance, its call site shall be considered as
> if after the application of the rewriting algorithm defined in F.4.1,
> which flattens properties and sequences, and substitutes actual arguments to
> sequence, property and checker instances for their corresponding formal
> arguments.
>
> 2. Add formal in the following sentence:
>
> Similarly, when $global_clock is used in an actual argument of a checker
> instance, the lookup rules shall be applied after the substitution of the
> actual argument in place of the corresponding formal argument inside the
> checker body.
>
> 3. In the description for the rules for having only one global clocking
> block. It would be good to explicitly state that global clocking is allowed
> in generate blocks. Currently the proposal says "
>
> Global clocking may be declared in a module, an interface, a checker, or a
> program. A given module, interface, checker or program instance in the
> elaborated design description shall contain at most one global clocking
> declaration. It shall be an error if there is more than one global clocking
> declaration in a given module, interface, checker or program instance in the
> elaborated design description. "
>
> But later on, in the rules it talks about generate blocks also. It would be
> good to mention generates in the above statements also.
>
> 4. In the example for generate, it is missing 'endcase'.
>
> 3213
>
> I do not understand the logic for picking up past value from postponed
> region of previous clock tick. Shouldn't the past value be picked up based
> on what assertions used in the previous clock tick ? I am wondering about
> checker vars which are assigned non-blockingly (in Re-NBA). Similarly the
> statement about $future_gclk(v) picking up value from the postponed region
> is not clear to me. Shouldn't the values be based on what assertions see in
> Observed region. If an assertion is using $future_gclk(), does that mean the
> assertion has to be evaluated in Postponed region ?
>
> *Ed:*
>
> 3213
>
> In 16.5.1, first item: If a variable is declared in a task, that variable
> is sampled as any other variable, independent of calls to the task.
>
> You mean task calls in match items? What about variables declared in
> functions called in Boolean expressions? Should this line have a little more
> explanation?
>
>
>
> In For example, if a is a variable, then the value of *const*’(a) in the concurrent
> context is the current value of a.
>
> Should it say concurrent assertion context, since concurrent context is not
> defined?
>
>
>
> I do not quite understand (in red)
>
> The change (or lack of change) is determined by comparing the sampled value
> of the expression with the sampled value of the expression evaluated in
> the Postponed region of the most recent strictly prior time step in which
> the clocking event occurred.
>
> Sampled value was defined as the value taken in the preponed region. Is
> this changing the definition for this particular case here? If not, then why
> to mention it since the sampled value is stable throughout the time step. If
> it changes the definition, then the sampled value in postponed region would
> reflect the changed value as a consequence of the clock tick. So, if the
> clock tick occurred just in the preceding time step, the current sampled
> value and the one from the preceding postponed region are the same. No
> change detected?
>
>
>
> Similarly in
>
> The other functions are defined as follows (the comparison is done between
> the sampled value at the invocation point and the sampled value in the
> Postponed region of the next tick of the global clock):
>
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.