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

Yes, this is good.
You need 2 commas here: "... fail action clock*, i.e.,* $error
Also, should the "else" be in courier? Thus,
.....By default, the fail action is executed. This task also affects the
execution of default fail action block*, i.e.,* $error, which is called in
case no *else* clause is specified for the assertion.
Ben

On Wed, May 18, 2011 at 11:49 PM, Kulshrestha, Manisha <
Manisha_Kulshrestha@mentor.com> wrote:

> Hi,
>
> You are right. How about changing the statement to:
>
> .....By default, the fail action is executed. This task also affects the
> execution of default fail action block i.e. $error, which is called in
> case no else clause is specified for the assertion.
>
> Manisha
> ------------------------------
> *From:* ben cohen [mailto:hdlcohen@gmail.com]
> *Sent:* Thursday, May 19, 2011 12:02 PM
>
> *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,
> 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.