RE: [sv-ac] Email ballot result (Due May 11 and May 16 )

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, and is
believed to be clean.