RE: [sv-ac] Reviewing 3191 (triggered method on sequence formals)

From: Kulshrestha, Manisha <Manisha_Kulshrestha@mentor.com>
Date: Fri Mar 11 2011 - 09:31:54 PST

Hi Erik,

There is nothing special about triggered. Whenever parser sees something
like s.triggered or f.triggered it just knows that it is a hierarchical
reference which is also part of primary in the expression. So this gets
parsed as an expression (it is the job of the tool to figure out that
this is method .triggered defined for sequences):

primary ::=

primary_literal

| [ class_qualifier | package_scope ] hierarchical_identifier

hierarchical_identifier ::= [ $root . ] { identifier constant_bit_select
. } identifier

 

Now consider the case (a ##1 b).triggered, I do not think there is
anything in the bnf of expression which will parse it. If we want to
parse it, we'll have to define something in the bnf for the expression
to take something like <sequence_expr . identifier>.

Thanks.
Manisha

________________________________

From: Seligman, Erik [mailto:erik.seligman@intel.com]
Sent: Friday, March 11, 2011 9:04 PM
To: Kulshrestha, Manisha; sv-ac@eda-stds.org
Subject: RE: [sv-ac] Reviewing 3191 (triggered method on sequence
formals)

Can you explain in more detail why this is the case? Right now I don't
see .triggered covered at all in A.2.10.

 

From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
Sent: Thursday, March 10, 2011 8:49 PM
To: Seligman, Erik; sv-ac@eda-stds.org
Subject: RE: [sv-ac] Reviewing 3191 (triggered method on sequence
formals)

 

Hi Erik,

 

One reason we want to only allow .triggered call on formals is because
that will not require any changes in the syntax. Having f.triggered is
like a hierarchical ref which will be parsed by existing BNF. But if we
allow .triggered on any sequence expression, then we need to enhance the
BNF to allow hierarchical ref kind of thing on a sequence expression.

 

Thanks.

Manisha

 

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Seligman, Erik
Sent: Thursday, March 10, 2011 11:37 PM
To: sv-ac@eda-stds.org
Subject: [sv-ac] Reviewing 3191 (triggered method on sequence formals)

Hi guys-I carried out my action item to take a look at this proposal.
Can someone remind me why we wanted to do an extension specific to
sequence formal arguments, instead of defining the triggered method for
general sequences? In particular, this paragraph seems very awkward to
me:

 

There is one case in which the rewriting algorithm produces a legal
flattened sequence which would not be legal in the source text: when an
actual argument is a sequence expression and it is substituted for a
reference to the corresponding formal argument standing as the operand
of a sequence method call. In this case, the substitution produces a
sequence expression, enclosed in parentheses, as the operand of the
sequence method call. This is illegal in the source text, but is allowed
as a result of the rewriting algorithm. All other cases in which the
flattened sequence is illegal shall result with an error.

 

Do we really want to make this such a special case? Would it really be
easier to define/implement this extension rather than just making the
method defined for any sequence expression?

 

 

 

 

 

Defining triggered method for sequence arguments
Can we allow a sequence method on formal arguments

i.e.
property p (sequence s);
       s.triggered;
endproperty

Mantis 3191
Jacob: It's not legal to call triggered method on sequence s. (because
of
       substitution semantics?). Could we do a smaller extention to
allow
       only this case?
       A more comprehensive proposal would be to allow calling the
triggered
       method on any sequence expression.

3191: Anupam and Erik will review this proposal

 

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is
believed to be clean. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Mar 11 09:32:27 2011

This archive was generated by hypermail 2.1.8 : Fri Mar 11 2011 - 09:32:33 PST