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

Manisha,
Thanks. BTW, the LRM does not have a definition for that.
Ben
On Wed, May 18, 2011 at 11:24 PM, Kulshrestha, Manisha <
Manisha_Kulshrestha@mentor.com> wrote:

> Hi Ben,
>
> The default fail action block in the last sentence, refers to the fail
> action block that is implicitly added when there is no fail action for an
> assertion. This task affects the implicit fail action also.
>
> Thanks.
> Manisha
>
> ------------------------------
> *From:* ben cohen [mailto:hdlcohen@gmail.com]
> *Sent:* Thursday, May 19, 2011 3:36 AM
> *To:* Kulshrestha, Manisha
> *Cc:* Korchemny, Dmitry; sv-ac@eda-stds.org
> *Subject:* 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.