From: James A. Markevitch (jam@magic.com)
Date: Sat Feb 12 2000 - 12:05:04 PST
> I think attribute proposal in general is very good idea. One
> additional feature that is needed in AMS simulation is need for some
> kind of "compiler directive" (maybe not right solution) to assign
> default attribute to say every wire declaration. This is needed to
> tell analog equation solver say that all wires default to 3 volt attribute
> unless there is explicit attribute attached to wire.
> If there a way to do this in current proposal?
> /Steve
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.
If I understand the intent of the proposals so far, we are supplying syntax
for attributes and their location in Verilog source files, but not much
in the way of semantic interpretation. Thus,
1. The 1364-2000 standard will specify where attributes can appear in
the language, syntactically.
2. The 1364-2000 standard will specify how attributes can be accessed
using the PLI.
3. The 1364-2000 standard will not specify the semantics of any
attributes, nor will it specify which attributes have non-local
extent.
4. Extensions to the Verilog language, such as the synthesis guildelines
(whatever the name of that group is), can specify the semantics of
certain attributes, such as translate_on/translate_off, global compiler
directives, etc.
I realize that this is somewhat awkward, since the syntax and PLI seem to
imply attachment to specific objects. See below for some thoughts on this.
The idea of global attributes makes a good case for allowing "zero or more"
attributes to be attached at any point in the syntax, instead of "zero or
one." Consider the following code:
module foo;
(* default_net_voltage=3.3 *)
(* net_voltage=5 *) wire a, b, c;
wire d, e, f;
mod1 submod1(a, b);
mod1 submod2(c, b);
endmodule
This sets the global default voltage to 3.3 and sets the voltage for
wires a, b, and c to 5. But, syntactically, wires a, b, and c have
two attributes attached to them and d, e, and f have none.
Here are some thoughts on handling the attachment of attributes to objects:
OPTION A: 1364-2000 specifies syntax, allowing "zero or more" attributes
in many places. It also specifies, for the PLI, which objects have
attributes and how to access them. However, the standard DOES NOT
SPECIFY WHICH ATTRIBUTES ARE ATTACHED TO OBJECTS or their semantics.
So, even though the syntax in the above example shows default_net_voltage
attached to the three wires a, b, and c, a tool might choose to attach
the attribute to d, e, and f, but not a, b, c, submod1, or submod2.
With this option, the relationship between syntax and object attachment
are completely unspecified by the standard. The text of the standard
should indicate this, of course.
OPTION B: 1364-2000 specifies syntax, allowing "zero or more" attributes
in many places. It also specifies, for the PLI, which objects have
attributes and how to access them. In addition, we provide the
concept of "local" and "global" attributes. By default, attributes are
attached to the "obvious" objects :-). Global attributes can be
specified using a syntax such as what Stu proposed (I prefer to use
lowercase "begin" and "end" since those are already reserved words and
seem perfectly appropriate). Thus, the example above becomes:
module foo;
(* begin default_net_voltage=3.3 *)
(* net_voltage=5 *) wire a, b, c;
wire d, e, f;
mod1 submod1(a, b);
mod1 submod2(c, b);
(* end default_net_voltage=3.3 *)
endmodule
The 1364-2000 standard would specify the attachment of local attributes.
Global attributes would have tool-specific meaning. For example, in
the above example, the tool decides which objects to attach
default_net_voltage to. In the example, it is attached to some of the
wires, but not the modules. From the PLI, the attribute
default_net_voltage would be accessible from wires d, e, and f.
The "begin" and "end" would be interpreted in source-file order, just
as some of the compiler directives are. If a user used a "begin"
attribute, but didn't "end" it, then it would cross into other
modules, etc. Note that begin/end opens up the parameter interpretation
problem:
parameter p = 1;
(* begin default_net_voltage=p *)
What if "p" is overridden in a module instantiation? The easiest
solution here is to disallow the use of parameters in begin/end
attributes for now. Maybe allow them in Verilog-2005? This shouldn't
be a big deal, since the problem we are trying to address here is
translate on/off and the cases that Steve Meyer points out.
OPTION C: 1364-2000 specifies the syntax of attributes, but does not
specify anything about where they can appear in the language. We
put attribute_instance into syntax, but don't use it in any productions.
We let vendors decide where attributes go and how they are attached.
The 1364-2000 specifies which objects may have attributes, from the
PLI point of view, but it is totally tool-specific how those objects
attain their attributes. This allows attribute-unaware tools to parse
attribute-annointed source. It is almost the same as making attributes
lexical entities, instead of grammatical entities, but not quite.
The "not quite" is an important distinction, since it specifies how
attributes themselves are parsed and allows for future extension to
the language to indicate the legal places for attributes.
If we run out of time, I would probably push for OPTION C. At least this
defines what attributes look like and that they can be expressions, etc.
But, if there is general happiness with attributes and we resolve the
global attribute/parameter issue, then I would lean toward OPTION B.
James Markevitch
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:12 PDT
and
sponsored by Boyd Technology, Inc.