Subject: Re: 1364.1 pragmas
From: David Bishop (dbishop@server.vhdl.org)
Date: Mon Sep 02 2002 - 12:26:23 PDT
-------- Original Message --------
Date: Thu, 29 Aug 2002 22:10:32 -0700
To: vlog-synth@server.eda.org, etf@boyd.com
From: Stuart Sutherland <stuart@sutherland-hdl.com>
Subject: Re: 1364.1 pragmas
Well, it's been fun watching from the sidelines, but I guess it's time I
add my $0.02 worth as a member of the 1364 PLI task force.
First from the PLI perspective, I don't think there is any issue at all. A
very simple clarification statement will address all the issues that have
been raised about the PLI.
The PLI (specifically, the VPI) treats each attribute as an object that has
a value and a name. A case statement, for example, can have any number of
attribute objects. If a tool wants to use the PLI to find what objects are
associated with a case statement, it is trivial to access each one, one at
a time, and read the name and value.
The PLI standard also has a general rule that if there is a defined order
to objects in the Verilog source code, those objects will be returned in
that order when accessed by the PLI. For example "iterating" on all the
ports of a module is guaranteed to return the ports in the same order in
which they are defined. The 1364-2001 makes no statement on whether
attributes have a defined order or not. A simple clarification from the
ETF would be to add a note to the VPI attribute diagram stating that
attributes are returned in the order in which they are defined in the
Verilog source code. The note would need to cover the unique case of
modules and UDPs, where attributes can be defined on both the definition
and on each instance. If two attributes have the same name, the 1364-2001
standard already defines which one wins. If they are different names, the
clarification would need to define which ones are returned first; the
attributes on the instance or the attributes on the definition.
Note that this clarification does not break the existing 1364-2001 standard
in any way. In fact, the clarification could go unspecified. The standard
does NOT say attributes are returned in an indeterminate order. It just
leaves it up to implementation. That's not to say we should deliberately
leave in an ambiguity. If we can add a clarification note regarding the
order in which the PLI returns attributes, we should. But if we don't
specify it, the standard is still correct.
So, I don't think the PLI has any real problems with the way the 1364.1
uses attributes, it only has an ambiguity.
However, Steven raises another issue, that cannot be solved by simply
specifying an order to attributes. Attributes have an implicit name space
local to the object with which they are associated. As Steven points out,
the multiple attribute definition:
(* synthesis, fullcase *) (* fv, fullcase=0 *) case ...
has a single attribute named "fullcase", which is associated with the
"case" statement.
What 1364.1 has tried to define is that one of the "fullcase" attributes in
this example is associated with the "synthesis" attribute--an attribute of
an attribute, so to speak. That is not 1364-2001 compliant. Attributes
can not have attributes in the current 1364 standard. The only fix to this
is to extend the 1364 standard to allow attributes to be associated with
other attributes. That would be an enhancement to 1364, not an erratum or
clarification. I, for one, do not want to go there.
I suggest that the solution is for the 1364.1 standard to define TWO ways
to specify attributes for synthesis. Using the fullcase example, the two
ways should be:
1) (* fullcase *) defines that software tools in general MAY treat the
associated decision statement as full, and that synthesis tools SHALL treat
the decision statement as full.
2) (* synthesis, fullcase *) defines the same "fullcase" as 1), above. The
"synthesis" attribute has no affect and is not necessary, but can serve as
good code documentation. The "synthesis" attribute makes it more obvious
that synthesis will be affected by the "fullcase" attribute.
I do not see any need for 1364.1 to define synthesis-specific attribute
names, such as (* syn_fullcase *) or (* synthesis_fullcase *). 1364.1 is
the first standard to make use of any of its proposed attribute names. If
a formal standard or a mixed-signal standard or some other standard comes
out after 1364.1 that needs a fullcase-like attribute (or any other 1364.1
attribute name), the later standard will have to either use the 1364.1 name
and accept that the attribute must be true or false for all tools, or
define a unique name that does not conflict with 1364.1.
That's my $0.02. There's no problem with the 1364 standard for
attributes. The PLI could use a simple clarification, but is OK with its
current ambiguous wording. The real issue is with the 1364.1 standard,
which is trying to specify that an attribute like "fullcase" is associated
with another attribute, named "synthesis". The 1364-2001 standard does not
allow that.
Stu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland-hdl.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland-hdl.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Mon Sep 02 2002 - 12:34:49 PDT