[sv-ac] Email ballot results (Due August-30)

2205 2571 3035
No Yes Laurence Bisht
Yes Yes Yes Eduard Cerny
Yes Yes Yes Ben Cohen
Yes Yes Yes Surrendra Dudani
Yes Yes No John Havlicek
Yes Yes Yes Tapan Kapoor
Yes Yes Yes Manisha Kulshrestha
Yes Yes No Scott Little
Yes Yes No Anupam Prabhakar
Yes Abstained Yes Erik Seligman
Yes Yes Yes Samik Sengupta
Yes Yes No Tom Thatcher

Issue 2571 passed: 11y/1a/0n
Issues 2205 and 3035 failed

Notes:

2205
Laurence: why the middle change is needed here? (20.2) - if insisting then the syntax should be changed.

2571
Erik: change seems unnecessary but I can live with it

3035

Tom:
What about the following case?

     checker check(x, clk);
         logic y;
         a1: assert #0 (x);

 always @clk begin
     y <=x;
 end

     endchecker

It seems that according to this proposal, the deferred assertion would
use the current value of x, while the assignment to the checker variable
y would use the sampled value. This could create confusion.

It seems that the only way to create a truly consistent semantics is one
of two choices: either keep the current semantics: all input arguments
to a checker are sampled. Or, remove all sampling semantics from
checker arguments. Variables inside a checker would then be sampled or
not sampled according to the rules which apply everywhere else.

John:
I think that rule proposed for sampling the RHS of checker NBAs needs to be scrutinized for interaction with enveloping procedural constructs that the writers of checker modeling code are going to need. I am worried that this is a step down a complicated path and that we should look for a simpler overall solution to the problem. Some motivating examples that show the interaction between checker modeling code and non-checker modeling code will be useful.

Also, I am not convinced by the motivation for the mantis. I think that a const cast could be added to $inferred_disable, either as a default actual argument or as an explicit actual argument to avoid sampling of the inferred rst signal.

Scott:
John and I discussed this mantis earlier today. I tend to agree with his thoughts although maybe not as strongly. Part of my problem with knowing how to vote on this item is understanding why it is important that the design variables are sampled in a checker. I think that if I could be given some intuition as to why/when this is important it would help me understand the "goodness criteria" for the proposed solution. I do understand that it is related to the fact that checker NBAs occur in re-NBA, but I haven't thought about the problem long enough to understand why this causes problems.

One use case I had kicking around in my head is this: I already have some modeling code and procedural concurrent assertions in a design. I would like to take those and encapsulate them in a checker for reuse. How hard is this to do? What issues might I have with sampling?

 I know these are very basic questions with regard to checkers in general, but it seems like an example along this line might also help others.

Anupam:
I agree with John - we need to consider the impact of this on the new procedural constructs that we are going to add and make sure that the sampling rules for checker arguments don't become confusing or complicated.

Ed:
I think that there is no confusion as to what should or should not be sampled. Already now in modules, variables that are use in deferred and immediate assertions are not sampled, those used in concurrent assertions (other than automatics, etc.) are sampled. In checkers it just adds that if used on rhs of assignments design variables are sampled

The question may arise once procedural control statements are used, allowing for automatic variables. should these be sampled or not? But that should be resolved when such statements are added. I think that the proposal on sampling should not depend on it.
(I.e. I disagree with John's solution to control sampling.)

Samik:
I have a friendly amendment suggestion here (Not sure if someone has already suggested this): In page 2, the paragraph starting with "Another issue with the existing definition of the existing definition of the checker variable sampling is the .." should be "Another issue with the existing definition of the checker variable sampling is the.."

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