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

My inclination would be to make the clock inference for always blocks more tolerant (more likely to use what's on the 'always' line, even if some of its expressions are used as in Ed's example), since RTL authors usually intend what's on the always line to be their true clocking event for the block.

But perhaps I'm missing some reasoning here. Does anyone remember the motivation for the original rule? Was it due to difficulties implementing tools that could handle this, or some insight into the usual intent of such code?

-----Original Message-----
From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]
Sent: Monday, May 03, 2010 9:57 AM
To: Seligman, Erik; 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

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.