Subject: RE: 1364.1 pragmas
From: Michael McNamara (mac@verisity.com)
Date: Fri Sep 06 2002 - 09:37:08 PDT
Jayaram Bhasker writes:
> Precedence: bulk
>
> Excellent discussions. And some very good ideas and feedback from
> many.
Agreed.
> With some proposing that the intent of the 1364 attributes was
> expected to be in a certain form that were not explicitly mentioned
> in the standard document.
>
> Here is my assessment of the situation so far:
>
> Option 1: Keep the attribute pragmas as currently described in
> 1364.1 draft since it does not violate the description of
> attributes as described in the 1364 standard. The issue Steve
> brought up about 1364, Sec 2.8, para 4, can easily be resolved by
> constraining the usage of attributes in 1364.1 by adding the
> following statement to the 1364.1 draft:
>
> "It shall be an error to redefine these attributes for the same
> language element.
One needs to be careful here: language elements are themselves
containers for other language elements, which might also have
attributes. One might attach an attribute to a module, and then
attach a different value for the same attribute to a statement
contained in the module, violating this new requirement.
Further, if we continue with the attribute contextual grouping
proposed in 1364.1 of
statement (* synthesis, effort=7 *) ... (* lint, effort=6 *) ;
this new restriction would directly invalidate very reasonable usages
of multiple attributes attached to the very same language element
directed at different contexts, and end up making, in this case, the
word 'effort' a totally reserved attribute so that is can not be used
by any other domain, which would then force each domain perhaps pick
disambiguating prefixes for their attributes; thereby making the
prefix attributes of 'synthesis', 'lint' and so on completely
redundant syntatic sugar.
> In addition, these attributes shall not be overloaded to mean
> something else and shall not be used in any other context other
> than the way they are defined in this standard."
So, this additional restriction would make it illegal for a Lint tool
to even look at an attribute that was prefixed with 'synthesis', such
as (* synthesis, fullcase *); and perform static correctness checking
of the fullcase specification? I find this to be a big disservice to
the industry. Today existing lint tools do process most of the
Synopsys // directives.
> Option 2: 1364 add new semantics to the attributes indicating what
> their new interpretations are (which shows that current 1364.1
> usage is illegal 1364). This needs to happen within the next 1-2
> weeks so that 1364.1 WG can go back and redo their work on
> pragmas. The target is still to make 1364.1 a standard this year.
>
> My preference is option 1...
>
> - bhasker
Viable options, as I see it, are:
A) 1364 adds an interpretation of 1364-2001 that requires tools
implementing APIs that fetch attributes of language elements
(e.g. the PLI) must present the attributes to their caller in a
manner that preserves source order. Perhaps this is your Option 2?
If done, this would make 1364.1's current definition work.
B) 1364.1 revises the definition of its attributes to eliminate the
contextual nature of the attributes; thereby making each attribute
self sufficient, and not require an ordered analysis.
Either proposal would work as far as I am concerned.
However, which ever we do, I feel very strongly we should do this in a
manner that does not hide this design data from any and all tools that
could reasonably be imagined might use the information. For example,
a simulator might go ahead and implement a parallel case statement
exactly as the synthesis tool would do, by examining the exact same
synthesis directives that the synthesis tool is looking at; thereby
exposing the design and verification team to the reality of the design
far earlier than might otherwise occur.
--
_
// Michael McNamara, Sr VP Technology <mac@verisity.com>
_ // 650-934-6888, 408-930-6875 Cell <http://www.verisity.com>
\\ // ___ ____ _ ___ _ ___ _ _ ___ ___ __ _ _ _ _
\\// |_ |___)|(___ |' | ` \ / | \ |_ (__ | / _ |\ |
\/ |__ | \ | ___)| | | |__/ |__ __)| \_/ | \|
This archive was generated by hypermail 2b28 : Fri Sep 06 2002 - 09:43:47 PDT