RE: [sv-ec] Re: Feedback from Freescale on name resolution issues

I agree with Mike that the one problem is that users have no mechanism
for explicitly referring to the enclosing context. I believe such an
enhancement would be a worthwhile addition that preserves backward
compatibility and user intent. I like Jonathan's idea of re-using the
"local" keyword for this purpose, however, I'd propose we use a more
regular syntax for resolving name: Either local::name or local.name (my
preference is for the former).

I'd also like to point out that it is currently easy for users to
explicitly refer to the properties of the object being randomized by
simply using the same name as the object handle, as in:

	obj.randomize() with { obj.a < obj.b; }

Since the handle name is local to the scope, the writer has complete
control over its name - as long as it is not the name of property that
happens to be a handle, this will always bind to the object's
properties.

	Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Francoise Martinolle
Sent: Monday, November 05, 2007 10:07 AM
To: Michael Burns; Gordon Vreugdenhil
Cc: Neil.Korpusik@Sun.com; Jonathan Bromley; sv-ec@eda.org
Subject: RE: [sv-ec] Re: Feedback from Freescale on name resolution
issues

I see 2 options:
option 1)
we want to preserve backward compatibility, then we are stuck
with resolving the simple names from inside the class object first
because this is
the way it has been...
We need a special syntax to refer to the enclosing scope of the call of
randomize.
Someone proposed "local(a)"

option 2) 
not backward compatible, resolve simple names using the standard naming
rules
(enclosing immediate scope first).
Use a special prefix to resolve into the class object (prefix of
randomize):
for ex "obj."

Francoise
    '
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Michael Burns
Sent: Tuesday, October 23, 2007 8:00 PM
To: Gordon Vreugdenhil
Cc: Neil.Korpusik@Sun.com; Jonathan Bromley; sv-ec@eda.org
Subject: Re: [sv-ec] Re: Feedback from Freescale on name resolution
issues


Hi folks,

In our methodology, I think it would be quite rare to have a cumbersome
select prefix - we're going to do our inline constraining in some kind
of testcase-specific driver object and the object we're randomizing will
be a local data member of that driver class or a function automatic
which we access using a simple name. Our testbench people expect to use
Neil's syntax, and don't see a problem with it.

The real issue I'm concerned about is not how to explicitly specify
binding into the object, but how to explicitly specify binding into the
local lexical scope. 
I think that's where we need the enhancement.

--Mike

Gordon Vreugdenhil wrote:
> 
> 
> Neil Korpusik wrote:
>> Jonathan Bromley wrote On 10/23/07 01:45 AM,:
>>> (7) In a modification of suggestion (2):  instead of putting
>>>     a list of names in the parens, provide just one identifier,
>>>     freely chosen by the programmer, which is to be treated as
>>>     an alias for the object being randomized:
>>>       obj.randomize() with (thing) {thing.x < thing.y + x;};
>>>
>>
>> Perhaps I am missing something here.
>>
>> Why can't we just use the following? Since obj is the thing being 
>> randomized, why can't we just use 'obj.' when we need to specify that

>> the variables used in the with clause are within obj?
>>
>>    obj.randomize() with {obj.x < obj.y + x;};
> 
> Neil, I think that this would effectively remove the current special 
> rules.  In addition,  this is painful if "obj" is a general select 
> prefix -- users would want/need to create a temporary handle of the 
> appropriate type to have manageable constraints.
> 
> Gord.
> 
> 
> 


--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.