Default clocking is in the scope of SV-EC.
I would like to hear from other Champions. If no one else shares my concern, I will withdraw it.
Shalom
From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
Sent: Wednesday, November 02, 2011 6:54 AM
To: Bresticker, Shalom; Korchemny, Dmitry; sv-ac@eda-stds.org
Cc: sv-champions@eda.org
Subject: RE: [sv-ac] RE: Mantis 3069
Hi Shalom,
Here is an example of default clocking (without any instances). It is currently not clear from the LRM if this default clocking is going to apply to assertion or not (or is it valid to have default clocking inside generate):
module test;
reg a, b;
.....
generate if (1)
begin
default clocking ck ....;
endgenerate
assert property (a |=> b);
endmodule
Suppose instead of default clocking, there is global clocking inside the generate. Should this global clocking apply to the assertion ? Whatever we decide for this case, can be extended for instances also.
Thanks.
Manisha
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Bresticker, Shalom
Sent: Tuesday, November 01, 2011 10:43 PM
To: Korchemny, Dmitry; sv-ac@eda-stds.org
Cc: sv-champions@eda.org
Subject: [sv-ac] RE: Mantis 3069
I think the issues are related.
Shalom
From: Korchemny, Dmitry
Sent: Tuesday, November 01, 2011 7:12 PM
To: Bresticker, Shalom; sv-ac@eda-stds.org
Cc: sv-champions@eda.org
Subject: RE: Mantis 3069
Yes, this is correct. I am talking about generate blocks and the syntactic scope.
Dmitry
From: Bresticker, Shalom
Sent: Tuesday, November 01, 2011 19:10
To: Korchemny, Dmitry; sv-ac@eda-stds.org
Cc: sv-champions@eda.org
Subject: RE: Mantis 3069
But for default clocking, it says,
"[This scope] does not include instantiated modules, interfaces, or checkers."
I understood 3069 to say the opposite for global clocking.
Shalom
From: Korchemny, Dmitry
Sent: Tuesday, November 01, 2011 7:06 PM
To: Bresticker, Shalom; sv-ac@eda-stds.org
Cc: sv-champions@eda.org
Subject: RE: Mantis 3069
Hi Shalom,
The same issue exist for a default clocking in 14.2:
Only one default clocking can be specified in a module, interface, program, or checker. Specifying a default
clocking more than once in the same module, interface, program, or checker shall result in a compiler error.
A default clocking is valid only within the scope containing the default clocking specification statement.
This scope includes the module, interface, program, or checker that contains the declaration as well as any
nested modules, interfaces, or checkers. It does not include instantiated modules, interfaces, or checkers.
It is not clear from here whether a default clocking may be specified in a generate block in a module, etc., and we wanted to clarify this for a global clocking at least. If you think this should be a problem, it should be possible to keep the same language for a global clocking as used for a default one.
Thanks,
Dmitry
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Bresticker, Shalom
Sent: Sunday, October 30, 2011 16:28
To: sv-ac@eda-stds.org
Cc: sv-champions@eda.org
Subject: [sv-ac] Mantis 3069
Hi,
I am concerned about the following rule for global clock resolution:
"a) Look for a global clocking declaration in the enclosing (or 'parent' in b)) module, interface, checker, or program instance scope, or a generate block therein."
So for example in the end of the proposal:
"The following example is illegal, because the module top in the elaborated design descritpion contains multiple global clocking declarations.
module top;
global clocking ck1 @(negedge clk);
subsystem sub1();
if (1) begin: b
global clocking ck2 @(posedge clk);
subsystem sub2();
end
endmodule"
The concept that the global clocking top.b.ck2 is considered as if declared in top, and an upward hierarchical search finds declarations in "a generate block therein" does not exist elsewhere in the language as far as I remember. I would be reluctant to break another consistency in the language.
Shalom
Shalom Bresticker
Intel LAD DA, Jerusalem, Israel
+972 2 589 6582 (office)
+972 54 721 1033 (cell)
http://www.linkedin.com/in/shalombresticker
---------------------------------------------------------------------
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. -- 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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Nov 1 23:13:42 2011
This archive was generated by hypermail 2.1.8 : Tue Nov 01 2011 - 23:13:45 PDT