Re: [sv-ec] dist operator should be removed from precedense table

If dist cannot occur in expression then it will fail when used with all 
operators with lower prior.
So putting dist into precedense table just mean do not use dist with 
operators with lower prior. This has not much sense.
Instead of catching errrors when dist is used in expression compiler can 
interpret this expression in the way that dist has the lowest prior and 
all will work with no necessity of using brackets.


DANiel

W dniu 2012-11-20 18:05, Tipp, Brandon P pisze:
> The rule that a dist cannot appear inside of another expression does not mean that you can ignore precedence.  Because it is an operator, it still must have a defined precedence against other operators. What you are proposing is to change the precedence of dist to be lower than || (perhaps just above the -> operator?)
>
> I can see an argument for that since it would allow a valid interpretation for an expression that is currently illegal. On the flip side, the dist operator is strongly related to the inside operator and they currently all have equal precedence.
>
> i.e., would you really prefer it if you had this:
> randomize () with { b || a dist {0, 1};};
> equivalent to this:
> randomize () with { (b || a) dist {0, 1};};
>
> but this:
> randomize () with {b || a inside {0, 1};};
> is still equivalent to this:
> randomize () with {b || (a inside {0, 1};};
>
> I think that will create greater confusion if inside and dist do not have the same precedence.
>
> -Brandon
>
> -----Original Message-----
> From: Daniel Mlynek [mailto:danielm@aldec.com.pl]
> Sent: Tuesday, November 20, 2012 2:55 AM
> To: Tipp, Brandon P
> Cc: Neil Korpusik; sv-ec@eda.org; danielm@aldec.com
> Subject: Re: [sv-ec] dist operator should be removed from precedense table
>
> Thank you for the response.
>
> Before I write my 1st mail I've checked where expr_or_dist can be used.
> It can be used in concurent assertions items and in constraints.
> In both those plases it cannot be a part of expression So it makes no sense to have it in precedence list  - it just make confusion to have it in the priority list. This is what I wanted to say.
>
> In expresion :
>
> randomize() with {b || a dist {0:=9, 1:=1};};
>
> you can ignore precedences bcos dist cannot be used in expression anyway so you can treat this as:
>
> randomize() with {(b || a) dist {0:=9, 1:=1};};
>
> and this is what probably all tools does.
>
> As per quotation  "dist expressions cannot appear in other expressions"
> it is ok to have redundancy but it would be more clear if such statement would be general for dist not only for dist in constraints so it is better to move this or dublicate it to general dist description or to assertion chapter.
>
> DANiel
>
>
> W dniu 2012-11-15 16:23, Tipp, Brandon P pisze:
>> The dist *operator* needs to have a defined precedence against other operators.
>> Based on the precedence table this:
>> randomize() with {b || a dist {0:=9, 1:=1};}; is the same as this:
>> randomize() with {b || ( a dist {0:=9, 1:=1});}; which should be
>> illegal (per the rule that a dist expression cannot appear in other
>> expressions) If it isn't, then there is either something wrong with your simulator or there the precedence table needs to be updated to reflect that dist has a lower precedence than ||.
>>
>> I agree that the statement "dist expressions cannot appear in other expressions" is redundant with the BNFs.  Much of the language in the LRM is redundant with the BNFs.  In the general case, larger expressions can be composed of smaller expressions and this statement clarifies a limitation for that general assumption, so I don't feel that this redundancy is egregious.  Furthermore, the original e-mail seems to assume that a dist can only exist inside of a constraint. That is not the case; search the spec for "expression_or_dist" and you will find numerous other contexts where a dist is legal and generally treated equivalently to an "inside" expression.  However, the statement "dist expressions cannot appear in other expressions" clarifies that even in those contexts, you cannot compose a larger expression from a dist expression.
>>
>> Just my thoughts on the subject.
>>
>> -Brandon
>>
>>
>>
>> -----Original Message-----
>> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
>> Neil Korpusik
>> Sent: Friday, November 02, 2012 6:10 PM
>> To: sv-ec@eda.org; danielm@aldec.com
>> Subject: [sv-ec] dist operator should be removed from precedense table
>>
>> Forwarding bounced email from danielm@aldec.com
>>
>> -------- Original Message --------
>> Date: Thu, 25 Oct 2012 01:33:29 -0700
>> From: Daniel Mlynek <danielm@aldec.com>
>>
>>
>> I do not understand why dist operator is in precedence table. From reading LRM I come to conlusion that this cannot be used with other operators in expressions anyway.
>> For constraints LRM says that :
>>
>> "*dist *expressions cannot appear in other expressions"
>>
>> this is redunand imho as even from reading BNF you can see that it can be us ed only with if..else, foreach, -> You cannot write :
>> randomize() with {*b ||*  (a dist{0:=9, 1:=1};)};
>>
>> Same for  assertions you cannot have
>> a1:assume property ( @(posedge clk) a dist {0:=40, 1:=60} *||b*) ;
>>
>> Having dist in precedence table one may think that below code is illegal:
>> randomize() with {*b ||*  a dist{0:=9, 1:=1};}; while it is the same as:
>> randomize() with {*(b ||*  a) dist{0:=9, 1:=1};};
>>
>> summarizing i think that:
>> - dist should be removed from precedence table
>> - statement "*dist *expressions cannot appear in other expressions""
>> should be removed
>>
>> DANiel
>>
>>
>>
>> --
>> 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.