RE: [sv-ac] Call to vote. Due August 30

Hi John,

Please, see my comments below in this color.

Thanks,
Dmitry

From: Havlicek John-R8AAAU [mailto:r8aaau@freescale.com]
Sent: Friday, September 03, 2010 6:19 PM
To: Korchemny, Dmitry; sv-ac@eda.org
Subject: RE: [sv-ac] Call to vote. Due August 30

Hi Dmitry:

Last things first:

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.
[Korchemny, Dmitry] Could you elaborate? Are you talking about something like:

checker check(a, rst = $nonsampled_inferred_disable); // ...

If you add an explicit actual argument then you lose the inferred disable:

check my_check(const'( x), const'(rst));

Let alone that this is ugly.

What I meant was to add the const cast, as in the declaration

   checker check(a, rst = const'($inferred_disable));

or in the instantiation

  check my_check(const'(x), const'($inferred_disable));

[Korchemny, Dmitry] I think that specifying const' cast for $inferred_disable in the instantiation is clumsy. One of the goals of introducing $inferred_disable was to type less. I don't think that the users will agree to write const'($inferred_disable) in the checker instantiation. Regarding specifying const' cast in the declaration, see below.

Some motivating examples that show the interaction between checker modeling code and non-checker modeling code will be useful.
[Korchemny, Dmitry] I am not sure I understand this statement. It is (and likely will remain) problematic to procedurally instantiate a checker having checker procedures. I don't know how to remedy this, and I am not sure that this feature would be very useful. Again, I may misunderstand your statement.

If we put assertions in a module and write modeling code there, we do not get sampling (unless we specifically ask for it with $sampled). The modeling code can be written in an RTL style. What is different in a checker that requires sampling? Is it the delayed execution of the checker modeling code to the Reactive and Re-NBA regions? I was wondering if an example showing checker modeling code that references module modeling code might illustrate the need for sampling.
[Korchemny, Dmitry] From this statement follows that we agree that the checker arguments should not be sampled, and this is the essence of my proposal. Performing checker variable sampling in Re-NBA is not related to this proposal. It was defined this way to allow NBA with .triggered sequence method, e.g.
                always @clk v <= s.triggered;

This capability is important in checkers.

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.
[Korchemny, Dmitry] I agree with this statement. At our last meeting we agreed to start working on Mantis "3033: Allow procedural control statements in checkers", and Ben took an action item to study it. You are, of course, welcome to join. As far as I can see, the conditions in the conditional statements to be introduced should have the same sampling rules as the RHS of the checker variable assignment. E.g., in

if (checker_arg) ...

checker_arg should be sampled. Therefore this does not seem to contradict the current proposal.

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.
[Korchemny, Dmitry] Any alternative proposal is welcome. If we have several proposals, we will choose the best one (or their combination). Our goal is not to stick to a specific solution, but to resolve the problems we have.

I am still a bit nervous without seeing how the sampling will be defined in the more general procedural contexts.
[Korchemny, Dmitry] In our last meeting we agreed to sketch all major enhancements in checkers and see how sampling definition is affected by them. Then we will be more confident.

J.H.

From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
Sent: Tuesday, August 31, 2010 3:16 AM
To: Havlicek John-R8AAAU; sv-ac@eda.org
Subject: RE: [sv-ac] Call to vote. Due August 30

Hi John,

Please, see my comments below.

Thanks,
Dmitry

From: Havlicek John-R8AAAU [mailto:r8aaau@freescale.com]
Sent: Monday, August 30, 2010 9:14 PM
To: Korchemny, Dmitry; sv-ac@eda.org
Subject: RE: [sv-ac] Call to vote. Due August 30

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.
[Korchemny, Dmitry] I agree with this statement. At our last meeting we agreed to start working on Mantis "3033: Allow procedural control statements in checkers", and Ben took an action item to study it. You are, of course, welcome to join. As far as I can see, the conditions in the conditional statements to be introduced should have the same sampling rules as the RHS of the checker variable assignment. E.g., in

if (checker_arg) ...

checker_arg should be sampled. Therefore this does not seem to contradict the current proposal.

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.
[Korchemny, Dmitry] Any alternative proposal is welcome. If we have several proposals, we will choose the best one (or their combination). Our goal is not to stick to a specific solution, but to resolve the problems we have.

Some motivating examples that show the interaction between checker modeling code and non-checker modeling code will be useful.
[Korchemny, Dmitry] I am not sure I understand this statement. It is (and likely will remain) problematic to procedurally instantiate a checker having checker procedures. I don't know how to remedy this, and I am not sure that this feature would be very useful. Again, I may misunderstand your statement.

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.
[Korchemny, Dmitry] Could you elaborate? Are you talking about something like:

checker check(a, rst = $nonsampled_inferred_disable); // ...

If you add an explicit actual argument then you lose the inferred disable:

check my_check(const'( x), const'(rst));

Let alone that this is ugly.

---------------------------------------------------------------------

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.
---------------------------------------------------------------------
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.