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));

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.

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.

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.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.