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

I think that the "allowed appearance" has to be restricted to arguments that are used as clocking events in covergroup, sampled-value functions etc. Or, should it be also allowed in the expressions? e.g., a <= $past(clk) where clk is the inferred clock?

ed

> -----Original Message-----
> From: Seligman, Erik [mailto:erik.seligman@intel.com]
> Sent: Monday, May 03, 2010 12:49 PM
> To: Surrendra Dudani; Eduard Cerny; 'Havlicek John-R8AAAU';
> Kulshrestha, Manisha
> 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
>
> Ah, I see. So we weren't talking about covergroup declarations, but
> covergroup instantiations.
>
> Would this correction cover all our concerns?
>
> b) No term in expression1 appears anywhere else in the body of the
> procedure, except in an assertion statement, expect statement, checker
> or covergroup instantiation, or sampled value function.
>
>
>
> -----Original Message-----
> From: Surrendra Dudani [mailto:Surrendra.Dudani@synopsys.com]
> Sent: Monday, May 03, 2010 9:21 AM
> To: Seligman, Erik; Eduard Cerny; Surrendra Dudani; 'Havlicek John-
> R8AAAU'; Kulshrestha, Manisha
> 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,
> The example below illustrates a modified example from the LRM:
>
> module m;
> int ra, low,high, clk;
>
>
> covergroup cg (ref int ra, input int low, int high ) @(posedge clk);
> coverpoint ra // sample variable passed by reference
> {
> bins good = { [low : high] };
> bins bad[] = default;
> }
> endgroup
>
> int va, vb,vx;
> always @(posedge clk) begin
> cg c1 = new( clk, 0, 50 ); // cover variable va in the range 0 to
> 50
> cg c2 = new( vb, 120, 600 ); // cover variable vb in the range 120
> to 600
> end
> endmodule
>
>
>
> -----Original Message-----
> From: Seligman, Erik [mailto:erik.seligman@intel.com]
> Sent: Monday, May 03, 2010 10:42 AM
> To: Eduard Cerny; Surrendra Dudani; 'Havlicek John-R8AAAU';
> Kulshrestha, Manisha
> 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 guys-- thanks for the comments.
>
> Don't forget that the term 'assertion statement' now applies to
> asserts, assumes, restricts, and covers. I assumed that by saying
> 'assertion statement' we would also include the entire statement,
> including the action block-- is this incorrect?
>
> So, we cover a good part of the comments below by removing the word
> 'concurrent' from my suggested correction below. But that then leaves
> - Sampled value functions in assignments: Do we need to limit this to
> assignments? Perhaps we should allow the use in sampled value
> functions in general.
> - Expect statements: I agree, it makes sense to exclude these.
> - Covergroups: Are these really allowed in procedural code? I had
> thought they were not. Can someone clarify?
>
>
> So, here's a proposed revision to rule (b) for further comment:
>
> b) No term in expression1 appears anywhere else in the body of the
> procedure, except in an assertion statement, expect statement, checker
> instantiation, or sampled value function.
>
>
> -----Original Message-----
> From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]
> Sent: Monday, May 03, 2010 5:26 AM
> To: Surrendra Dudani; '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
>
> 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.