Re: [sv-ac] Re: [sv-ec]e-mail ballot Closes Wednesday February 20 2008, 11:59pm PST

From: Thomas Thatcher <Thomas.Thatcher_at_.....>
Date: Fri Feb 22 2008 - 08:25:26 PST
Hi Arturo,

Thanks for taking a look.

In that example, I had clk defined as an argument to the covergroup.  I 
thought that the clocking event @(posedge clk) would refer to the formal 
argument (ref logic clk), not to any external definition of clk.  I even 
tried an example to make sure this would work, and it did seem to work 
for me.  Is this correct?

Thanks,

Tom

Arturo Salz wrote:
> Tom,
> 
> This proposal clears up all my prior issues.
> One thing I'd like to point out is that in the first example of section
> 16.18.6 (see below) 
> 	covergroup cg_active (ref logic clk, ref logic active, ref bit
> active_d1)
> 		@(posedge clk);
> As the covergroup declaration lies outside the checker, its clocking
> event is bound to the "clk" signal visible at the covergroup declaration
> site. While this doesn't represents a fundamental problem, it does
> deviate fro the intent of the original proposal in which the clocking
> expression was bound to the checker port. 
> From a methodology perspective, this may not be the best mechanism and
> perhaps the proposal should mention that.
> 
> 	Arturo
> 
> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Thomas Thatcher
> Sent: Thursday, February 21, 2008 5:33 PM
> To: Gordon Vreugdenhil
> Cc: Steven Sharp; dmitry.korchemny@intel.com;
> Mehdi.Mohtashemi@synopsys.COM; sv-ec@eda-stds.org; sv-ac@eda.org
> Subject: Re: [sv-ac] Re: [sv-ec]e-mail ballot Closes Wednesday February
> 20 2008, 11:59pm PST
> 
> Hi Gord,
> 
> I have re-written the proposal to allow only covergroup instances within
> 
> a checker.  Take a look and see if that answers some of the most serious
> 
> problems.  The proposal is attached.
> 
> Thanks,
> 
> Tom
> 
> Gordon Vreugdenhil wrote:
>>
>> Steven Sharp wrote:
>>>> From: Gordon Vreugdenhil <gordonv@model.com>
>>>> But that is immaterial to my question.  If you have an auto
> declaration
>>>> in the enclosing scope, can a checker instance refer to that?  No
>>>> one has (yet) made any restrictions regarding the resolution rules,
>>>> so I am assuming that the answer is yes.
>>> In defense of this part of the proposal, I think the same issue
> arises
>>> for static variable initializers.  An initializer on a local static
>>> variable could be within the scope of an automatic variable, and I
> don't
>>> see anything in the LRM restricting it from referencing one.
> However,
>>> clearly it cannot be allowed to do so.  Automatic variables are
> created
>>> by procedural execution entering their scope, and static variable
>>> initializers are not executed in the context of a procedural entry
> into
>>> the scope.
>>
>> I agree on both fronts.  My concerns are mostly that while I can
>> reason about why something like:
>>     initial begin:b
>>         automatic int x = 1;
>>         static int y = x;
>>       ...
>> should be illegal, it is harder for me to reason about things
>> in the AC space since in various contexts more "synthesis"
>> like behaviors seem to be expected and I haven't quite gotten to
>> a point where I can predict what AC expects the behavior to be.
>>
>>> If concurrent assertions and checkers in procedural code were
> similarly
>>> static objects, independent of any procedural execution of the code,
> then
>>> things would be simplified.  However, Mantis 1995 and 2110 break that
>>> conceptual model.
>> This is also what I'm struggling with.  Some of the aspects
>> of checkers appear to in fact be static (the text requires
>> that for checker variables, etc), but it isn't quite clear
>> to me yet exactly what the boundaries are and whether those
>> boundaries are well formed.
>>
>> Part of my difficulty lies in lack of time to get everything in
>> my head; part of it is also that various relevant pieces of
>> the semantics and rules appear to be distributed in a half-dozen
>> Mantis items and I don't know what is all relevant.
>>
>> Gord.
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Feb 22 08:49:34 2008

This archive was generated by hypermail 2.1.8 : Fri Feb 22 2008 - 08:50:41 PST