Re: BTF Attribute proposal (problem from AMS Verilog)

From: Steven Sharp (sharp@cadence.com)
Date: Sat Feb 12 2000 - 14:51:16 PST


> This is a close analog to the translate_on/translate_off problem, both of
> which require the concept of a global attribute, instead of an attribute
> attached to a specific object.

I disagree that these have the same problem. A Verilog design hierarchy is
a tree structure (actually a forest of trees, since there can be multiple
top-level modules). An attribute can be effectively attached to an entire
subtree of the design by attaching it to the object at the root. This can
be used to provide the kind of globalness desired by Steve Meyer.

The problem with translate_on/translate_off is that it is being applied to
a section of sequential source text, which is not directly represented in
the design hierarchy.

If this sequential text can span module boundaries, then even more serious
problems arise. Attributes can get values from parameters, which is only
meaningful within the module where that parameter is defined. Separate
compilation or library reference (e.g. XL's -y -v options) can refer to
a module without the surrounding text. The sequential text model just
doesn't fit in well.

We don't have the time to solve this problem, if a reasonable solution even
exists. If we hastily add some kind of special attribute, there could be
other problems we haven't foreseen. Also, the PLI would still need to add
a way of accessing them, potentially leading to more mistakes. Note that
the PLI doesn't provide a way of accessing the "module_item" version of
attributes that was apparently supposed to allow translate_on/off.

Weakening them to purely syntactic constructs isn't a solution either. It
avoids any direct mistakes, but makes them so weak that they won't be
used. Attaching attributes to objects and allowing a PLI mechanism to
access them is a minimal first step to make them useful.

At this point, I am going to propose removing the synthesis_on/off example
to avoid misleading anyone. That doesn't prevent someone from coming up with
a working solution that can be included in the next standard. Meanwhile,
every other situation I know of involves attaching attributes to objects,
and it would be good for that to be standardized.



This archive was generated by hypermail 2.1.4 : Mon Jul 08 2002 - 12:54:12 PDT and
sponsored by Boyd Technology, Inc.