Re: [sv-ac] Can checker assign value to variable outside its boundary?

See last thread below for an example of my issue. This sentence in 17.2 is
confusing. What does it mean?
17.2 "Variables used in a checker that are neither formal arguments to the
checker nor internal variables of the
checker are resolved according to the scoping rules from the scope in which
the checker is declared."

Also in 17.2
"Clock and disable iff contexts are inherited from the scope of the checker
declaration (but see 17.4 for usage of
context value functions for passing the instantiation context to the
checker). For example:
module m;
default clocking @clk1; endclocking
default disable iff rst1;
checker c1;
// Inherits @clk1 and rst1
...
endchecker : c1
...
Am OK with that. So this in a way violates the hierarchical referencing
requirement, but that is an exception.
My question is then, which "Variables used in a checker that are neither
formal arguments to the checker nor internal variables of the
checker" is the LRM talking about?

Thanks,
Ben

On Mon, Aug 24, 2009 at 12:33 AM, ben cohen <hdlcohen@gmail.com> wrote:

> Dmitry,
> Thanks for the explanation. Since this is an LRM, the rules need to be
> defined. I'll submitted a Mantis so as to keep track of this point.
>
> 0002858 <http://www.eda-stds.org/svdb/view.php?id=2858> ErrataSV-AC major
> new 2009-08-24 Clarify the rules for assigning a value to a non-checker
> variable from within a checker
> Thanks again.
> Ben Cohen
> On Mon, Aug 24, 2009 at 12:11 AM, Korchemny, Dmitry <
> dmitry.korchemny@intel.com> wrote:
>
>> Hi Ben,
>>
>>
>>
>> Though I don’t see any benefit in assigning a value to a non-checker
>> variable in a checker, it is not formally forbidden in the LRM. I agree that
>> the LRM should be explicit about it, and if the assignment of external
>> variables is allowed, it should be stated in what region it is performed.
>>
>>
>>
>> The reason why all checker arguments are input is not the desire to
>> disallow changing external variables in a checker, but it is a temporary
>> limitation. The checkers may serve as building blocks for formal
>> verification, and for this purpose the output checker arguments would be
>> very useful. For example,
>>
>>
>>
>> checker check1(bit a, event clk); // Contains assertions
>>
>> bit b;
>>
>> check2 c(a, b, clk);
>>
>> assert property (@clk a |=> b);
>>
>> endchecker
>>
>>
>>
>> checker check2(bit a, event clk, output bit b); // Performs modeling
>>
>> always @clk
>>
>> b <= a;
>>
>> endchecker
>>
>>
>>
>> We didn’t allow output arguments in checkers because of the tight time
>> schedule.
>>
>>
>>
>> Regards,
>>
>> Dmitry
>>
>>
>>
>> *From:* owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] *On
>> Behalf Of *ben cohen
>> *Sent:* Monday, August 24, 2009 9:36 AM
>> *To:* sv-ac@server.eda.org
>> *Subject:* [sv-ac] Can checker assign value to variable outside its
>> boundary?
>>
>>
>>
>> 17.7.1 states "It shall be illegal to reference a checker variable using
>> its hierarchical name in assignments"
>>
>> (Note: that means that a module cannot access a checker's variable) That
>> is not my question.
>>
>> 17.2 states "Variables used in a checker that are neither formal arguments
>> to the checker nor internal variables of the
>>
>> checker are resolved according to the scoping rules from the scope in
>> which the checker is declared."
>>
>> However, *nowhere in the LRM does it state that a checker cannot assign a
>> value to a variable in the checker's boundary. *
>>
>> *Thus, by omission, it is legal to assign a value to a variable outside
>> the checker's boundary. *
>>
>> Maybe it's a misconception on my part, *but all ports of a checker are
>> inputs. The obvious intent in making ports inputs is prevent the assignment
>> to objects outside the checker boundary. *In a way, allowing such
>> assignments defeats the requirement that ports must be inputs.
>>
>> *Question*: *Can a checker assign a value to a variable in it's scope
>> declaration? *
>>
>> Below is an example of my understanding. However, LRM is unclear on
>> this.
>>
>> *module *test;
>>
>> logic *a*, b, c. clk;
>>
>> task t;
>>
>> logic t1;
>>
>> t1<= 1'b1;
>>
>> a <= t1;
>>
>> endtask
>>
>>
>>
>> some_other_module *m_other*; // has local variable* z*
>>
>>
>>
>> checker c(logic clk);
>>
>> logic x, y;
>>
>> always (@ (posedge clk) begin
>>
>> * a <= 1'b0; // ILLEGAL ?? Can write to outside
>> checker boundary? *
>>
>> * t.t1 <= 1'b1; ILLEGAL ?? *
>>
>> x <= 1'b1; // OK
>>
>> y <= b; // OK, can read b
>>
>> *m_other.z <= 1'b1; // ILLEGAL* ??
>>
>> end
>>
>> endchecker : c
>>
>> Ben Cohen
>>
>>
>>
>>
>> --
>> 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.