[sv-ec] Re: [sv-ac] RE: Mantis 3069

I need some clarification. aren't global clocking and default clocking
separate issues?
From LRM 14.14 "One clocking block may be declared as the global clocking
for an entire elaborated SystemVerilog model".
Thus global clocking is a clocking block. I thought that the way it is
used with assertions is as follows:
*module *top;
    *logic *clk100, req, ack;
    *global clocking *sys_cb @( posedge clk100); endclocking : sys_cb
    *default clocking* sys_cb; // specifies a default clock
    a1 : *assert property*(
            *@$global_clock* // overrides the default clock. In this case
it’s the same clock
            req |=> s_eventually ack);
endmodule : top

Thus, the assertion needs to specify either a clocking event or a clocking
block. It cannot use the global clocking as the "default clocking" unless
there is a "default clocking" statement.
Ben

On Wed, Nov 2, 2011 at 1:55 PM, Francoise Martinolle <fm@cadence.com> wrote:

> **
> I agree with Shalom.
>
> Any declaration inside a generate block is only directly visible inside
> that generate block scope. There should not
> be exception to that rule with global clocking blocks.
> module top;
> int i;
>
> generate if (1)
> begin :g1
> reg a;
> end
>
> endgenerate
>
> initial
> i = a; // This should give a error as there is no "a" visible here
> // however you could use a hierarchical reference to a as in
> : i = g1.a;
>
> endmodule // top
>
>
> I am also uncertain why would someone put somethins apparently global
> inside a generate?
>
> Perhaps you should be considering the ability to associate a global
> clocking with a global clocking identifier
>
>
> module test;
>
> **global clocking g1.ck;**
>
> reg a, b;****
>
> …..****
>
> generate if (1) ****
>
> begin : g1
>
> globak clocking ck ….;****
>
> endgenerate****
>
> ** **
>
> assert property (a |=> b);****
>
> endmodule****
>
> ** **
>
> ** **
> If you want the assertion to use the global clocking defined inside a
> generate, why would you put the assertion outside the generate block?
>
> Francoise
> '
>
> ------------------------------
> *From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On Behalf Of *Prabhakar,
> Anupam
>
> *Sent:* Wednesday, November 02, 2011 2:44 PM
> *To:* Bresticker, Shalom; Kulshrestha, Manisha; Korchemny, Dmitry;
> sv-ac@eda-stds.org
> *Cc:* sv-champions@eda.org; sv-ec@eda.org
> *Subject:* [sv-ec] RE: [sv-ac] RE: Mantis 3069
>
> I don’t think we should mix default clocking with global clocking. The
> reason why it makes sense to let a global clocking declared inside a
> generate scope be visible in the module scope is because global clocking
> applies to all the instantiated modules also. If we do not allow this then
> the user will have to write all module instances in each case of the
> generate statement – this is not convenient. There is no such need for
> default clocking and we should not even consider making this exception for
> default clocking. Also, global clocking is ‘global’ in some sense and it
> might be ok to let be visible outside the generate scope where it is
> declared.****
>
> ** **
>
> Anupam****
>
> ** **
>
> *From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of *Bresticker,
> Shalom
> *Sent:* Tuesday, November 01, 2011 11:12 PM
> *To:* Kulshrestha, Manisha; Korchemny, Dmitry; sv-ac@eda-stds.org
> *Cc:* sv-champions@eda.org; sv-ec@eda.org
> *Subject:* RE: [sv-ac] RE: Mantis 3069****
>
> ** **
>
> 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* <http://www.mailscanner.info/>, and is
> believed to be clean. ****
>
> --
> 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* <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.