RE: [sv-ac] Q: fix for rule (b) in 16.15.6 to allow inferred clock when expression appears in procedural assertion

If I may add - probably also allowed in sampled value functions in assignments.
ed

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Surrendra Dudani
> Sent: Monday, May 03, 2010 8:12 AM
> To: 'Havlicek John-R8AAAU'; Kulshrestha, Manisha; Seligman, Erik
> Cc: sv-ac@eda.org
> Subject: RE: [sv-ac] Q: fix for rule (b) in 16.15.6 to allow inferred
> clock when expression appears in procedural assertion
>
> On the same line of thinking, it should be allowed in other places
> which perform monitoring functions such as covergroups.
> Surrendra
>
> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Havlicek John-R8AAAU
> Sent: Sunday, May 02, 2010 10:43 PM
> To: Kulshrestha, Manisha; Seligman, Erik
> Cc: sv-ac@eda.org
> Subject: RE: [sv-ac] Q: fix for rule (b) in 16.15.6 to allow inferred
> clock when expression appears in procedural assertion
>
> I agree with Manisha.
>
> J.H.
>
> -----Original Message-----
> From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
> Sent: Saturday, May 01, 2010 12:25 AM
> To: Havlicek John-R8AAAU; Seligman, Erik
> Cc: sv-ac@eda.org
> Subject: RE: [sv-ac] Q: fix for rule (b) in 16.15.6 to allow inferred
> clock when expression appears in procedural assertion
>
> Hi,
>
> I think immediate assertions, deferred assertions, expect statement
> (including its action block) and sampled value functions should also be
> excluded. How about action blocks of assertions (immediate and
> concurrent) ? I think they should also be excluded.
>
> Manisha
>
> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Havlicek John-R8AAAU
> Sent: Saturday, May 01, 2010 6:13 AM
> To: Seligman, Erik
> Cc: sv-ac@eda.org
> Subject: RE: [sv-ac] Q: fix for rule (b) in 16.15.6 to allow inferred
> clock when expression appears in procedural assertion
>
> Hi Erik:
>
> Did you consider whether it should be allowed to reference expression1
> in immediate or deferred assertions?
>
> J.H.
>
> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Seligman, Erik
> Sent: Friday, April 30, 2010 10:57 AM
> To: sv-ac@eda.org
> Subject: [sv-ac] Q: fix for rule (b) in 16.15.6 to allow inferred clock
> when expression appears in procedural assertion
>
> I have the action item to put together a proposal for this one.
> It's looking to me like it might be a simple change to rule (b):
>
> b) No term in expression1 appears anywhere else in the body of the
> procedure, except in a concurrent assertion statement or checker
> instantiation.
>
> Does anyone think this needs to be something more complicated?
>
>
>
> >"Within the event control of the procedure, there is exactly one event
> >expression that satisfies both of the following conditions:
> >
> >a) The event expression is of the form edge_identifier expression1 [
> >iff
> >expression2 ] and is not a proper subexpression of an event expression
> >of this form.
> >
> >b) No term in expression1 appears anywhere else in the body of the
> >procedure."
> >
> >However, look at this example:
> >------------
> >default clocking dclk @(posedge clk);endclocking
> >//<<<------- clk used in default clocking
> >always @(negedge clk) begin //clk used in
> event
> >control in procedural code
> > as1: assert property (a ##1 a);
> > as2: assert property (@(posedge clk) a ##1 a);
> >//<<<-------- clk used inside body of the procedure
> >
> >end
> >
> >-----------
> >
> >I believe most of us would think negedge clk should be inferred as the
> >clock for as1, but a literal reading of rule b would force a non-
> >inference of the clocking event due to the use of clk in as2. In this
> >interpretation, as1 would get the default clock.
> >
> >Thus, we may need an exception to rule (b) to state that appearances
> of
>
> >the clocking event inside concurrent assertion statements are OK.
> >
>
>
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
>
>
>
>
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>

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