[sv-bc] Re: [sv-ec] [sv-ac] 1549 and inside operator

Korchemny, Dmitry wrote:
> I agree, there are many issues here. I think that at the very least
> there should be a note in the LRM that this construct is illegal in the
> untyped context, but I would like to find some satisfactory solution (if
> it exists).

The LRM already talks about legality in terms of "assignment like contexts"
in 10.8.  Perhaps there should be one line added --
     - passing of a value to an untyped formal of a sequence is not
       an assignment like context

"Sequence" here should be replaced by the universe of untyped
contexts with the assertions constructs.  This would, for
example, likely apply to various forms of "let" as well.

I don't really see any way to solve this for untyped scenarios
without introducing new syntax to implicitly build homogeneous
arrays.  But since an array literal (5.11) already has direct syntax
I don't really see a compelling reason to add new syntax for the
value.

I would have serious questions about trying to define implicit typing
for aggregates specified with the current syntax.

Gord.



> 
> Thanks,
> Dmitry
> 
> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
> Sent: Wednesday, October 10, 2007 6:51 PM
> To: Korchemny, Dmitry
> Cc: sv-ac@server.eda.org; sv-bc@server.eda.org; sv-ec@server.eda.org
> Subject: Re: [sv-ec] [sv-ac] 1549 and inside operator
> 
> Korchemny, Dmitry wrote:
>> Maybe the problem is in the vague definition of 'inside' operator?
>> Essentially it requires an argument list as its second argument, but
> SV
>> does not have such a construct.
> 
> That isn't the only issue.
> 
> For an aggregate (a '{}) one needs a type context in order to
> determine the type of the elements.  Since the type cannot
> be inferred here, we cannot determine the sizing, sign, etc.
> of even integral terms.  If you attempt to make this all
> self-determined, you will not in general end up with a
> homogenous type and will cause problems elsewhere in the
> language.
> 
> Gord.
> 
> 
> 
>> Thanks,
>> Dmitry
>>
>> -----Original Message-----
>> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
>> Sent: Wednesday, October 10, 2007 6:33 PM
>> To: Korchemny, Dmitry
>> Cc: sv-ac@server.eda.org; sv-bc@server.eda.org; sv-ec@server.eda.org
>> Subject: Re: [sv-ec] [sv-ac] 1549 and inside operator
>>
>>
>>
>> Since "x" and "y" are untyped, I don't know what to do with
>> the `{1, 3, 5} form.  There is no type that I can appeal to
>> in order to determine what to produce.
>>
>> So I don't think that what you have is valid at all.
>>
>> I guess that you could have:
>>     typedef int arr[$];
>>
>>    ...   s(a, arr'('{1,3, 5}))
>>
>> but I don't think you can use the '{} form with an
>> untyped formal and have the type be inferred.
>>
>> Gord.
>>
>>
>> Korchemny, Dmitry wrote:
>>> Hi all,
>>>
>>>  
>>>
>>> I have the following use case that is directly (or indirectly)
> related
>>> to 1549 resolution. Consider the following sequence:
>>>
>>>  
>>>
>>> sequence s(x, y);
>>>
>>> ##1 x inside {y};
>>>
>>> endsequence
>>>
>>>  
>>>
>>> What is the right way to pass a set to this sequence instantiation in
>> a 
>>> concurrent assertion? Should it be
>>>
>>>  
>>>
>>> assert property(@clk  s(a, '{1,3, 5});
>>>
>>>  
>>>
>>> ?
>>>
>>>  
>>>
>>> Or should other (which) syntax be used?
>>>
>>>  
>>>
>>> It looks like the LRM does not define it precisely.
>>>
>>>  
>>>
>>> Thanks,
>>>
>>> Dmitry
>>>
>>> ---------------------------------------------------------------------
>>> 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.
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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