RE: [sv-ac] 2804 proposal uploaded

I believe the problem is that without an edge specifier, if the always block has an arbitrary sensitivity list, we don't want to infer an arbitrary sensitivity signal as a clocking event & incorrectly override the default/global clocking.

I tried to write the proposal so that if the always block is triggered by an event (clocking block or event variable), this will be inferred as the clock-but if the always block is triggered by a non-event variable or something of unknown type, we only infer a clock if there is an edge. In these situations, the user needs to explicitly specify a clock for the properties. I think this is consistent with the current philosophy.

Remember that we're dealing here with kind of a messy rule that (I think) was originally inserted for backward-compatibility: ultimately, it's much safer to use explicit default clocking declarations if there is any doubt.

Does that make sense? Or do you have a solution that would cover the situation you mention?

From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
Sent: Tuesday, June 01, 2010 11:37 PM
To: Seligman, Erik; Korchemny, Dmitry; sv-ac@server.eda.org
Subject: RE: [sv-ac] 2804 proposal uploaded

Hi Erik,

My main concern with this is that in case of hierarchical references (e.g. always @(top.cb)), the incremental flow will not be able to infer clocks at compile time. In this case the cb could be a clocking block, event or just a variable. Since rule (2) eliminates any possibility of inferring 'reset' as the clock, why do we need an edge for inferring clock ? Also, when user writes the clock explicitly for an assertion, there is no such rule about having an 'edge'. Without, edge specifier, it means any edge in Verilog.

Thanks.
Manisha

________________________________
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Seligman, Erik
Sent: Wednesday, June 02, 2010 3:33 AM
To: Korchemny, Dmitry; sv-ac@server.eda.org
Subject: [sv-ac] 2804 proposal uploaded
Hi guys-I have uploaded a new proposal at http://www.verilog.org/mantis/view.php?id=2804, which I think captures the results of this morning's discussion. Please take a look & comment if further changes are needed.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.