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

Hi Manisha,

I don't think this is a useful behavior. One of the reasons to write deferred assertions in checkers is the ability to track changes in the procedural flow. Also, I would like to understand how you handle assign y = x; I don't see this statement in the resulting code.

Thanks,
Dmitry

From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
Sent: Tuesday, August 16, 2011 10:11
To: Korchemny, Dmitry; sv-ac@eda-stds.org
Subject: RE: [sv-ac] Call to vote: Due August 15

Hi Dimitry,

I feel as long as we define and explain the functionality of these procedures correctly there is no need to put restrictions about their usage. Static deferred assertions themselves are running independently as procedural code so their behavior should be clarified when the checker is instantiated procedurally. Here is your example:

module m (logic clk, a);
always_ff @(posedge clk) begin
a = 1'b0;
c check1(a);
a = 1'b1;
c check2(a);
end
endmodule : m

checker c(x):
var type(x) y;
assign y = x;
a1: assert #0 (y);
endchecker

The static assertion a1 should behave as if it is outside of procedural code (different from static concurrent assertions). So, the overall effect should be like this:

module m (logic clk, a);
always_ff @(posedge clk) begin
a = 1'b0;
a = 1'b1;
end

a1: assert #0 (a);
endmodule : m

So, a1 should behave as if it is outside of procedural code in module. This is consistent with rest of the procedural code in checkers (it runs independent of where checker is instantiated). Only static concurrent assertions trigger differently based on instantiation of checker. If checker writer has to use 'y' instead of 'x', he has to use 'assert final...' as he knows that assign will get evaluated in reactive region. So, the writer of the checker does not need to worry if the checker is going to be used in procedural code or outside of it.

Thanks.
Manisha

From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
Sent: Tuesday, August 16, 2011 11:54 AM
To: Kulshrestha, Manisha; sv-ac@eda-stds.org
Subject: RE: [sv-ac] Call to vote: Due August 15

Hi Manisha,

I don't think that we throw away the well-defined functionality. The checkers may be instantiated in procedural code. Usually you don't instantiate procedurally very complex checkers that contain assertion modeling.

However, we can keep the definition backward compatible if we say that the checkers containing continuous assignments, always_comb and always_latch cannot be instantiated procedurally. Would it address your concern?

Thanks,
Dmitry

From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
Sent: Tuesday, August 16, 2011 09:16
To: Korchemny, Dmitry; sv-ac@eda-stds.org
Subject: RE: [sv-ac] Call to vote: Due August 15

Mantis 3033 ____ Yes __X__ No
http://www.eda-stds.org/mantis/view.php?id=3033
http://www.eda-stds.org/mantis/file_download.php?file_id=5279&type=bug

I also feel that putting the restriction that procedurally instantiated checkers can not have any procedural code is a big restriction and also backward incompatible. The example of deferred assertion provided is not a real example as deferred assertions are not used in that way and having this restriction just so that deferred assertions work correctly is not right. In the last LRM, a lot of effort was put to define the functionality of checker instantiations in procedural code. Why are we throwing away all that well defined functionality. This looks like a big restriction as checkers in procedural code will not be able to have any modeling code.

Mantis 2328 __X__ Yes ____ No
http://www.eda-stds.org/mantis/view.php?id=2328
http://www.eda-stds.org/mantis/file_download.php?file_id=5274&type=bug

Friendly amendment:

Change the following sentence:
- Any dynamic data type elements captured for assertion evaluation shall continue to exist within the scope of the
assertion until the assertion evaluation completes.

To

- Elements of dynamic arrays, queues, and associative arrays that are sampled for assertion expression evaluation may get removed from the array or the array may get resized before the assertion expression is evaluated. These specific array elements sampled for assertion expression evaluation shall continue to exist within the scope of the assertion until the assertion expression evaluation completes.

Mantis 3295 __X__ Yes ____ No
http://www.eda-stds.org/mantis/view.php?id=3295<http://www.eda-stds.org/mantis/view.php?id=2328>
http://www.eda-stds.org/mantis/file_download.php?file_id=5277&type=bug

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