Subject: Re: 1364.1 pragmas
From: David Bishop (dbishop@server.vhdl.org)
Date: Mon Sep 02 2002 - 12:37:38 PDT
-------- Original Message --------
Date: Fri, 30 Aug 2002 17:09:34 -0400 (EDT)
From: Steven Sharp <sharp@cadence.com>
Reply-To: Steven Sharp <sharp@cadence.com>
Subject: Re: 1364.1 pragmas
To: vlog-synth@server.eda.org, etf@boyd.com, stuart@sutherland-hdl.com
>From: Stuart Sutherland <stuart@sutherland-hdl.com>
>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.
Thanks for filling us in. That is useful information.
> 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.
Actually, it doesn't. Neither one wins. From the HDL viewpoint being
used in Section 2.8, they are attached to different language elements:
the definition and the instance. That means that neither one replaces
the other. The PLI interface provides access to both sets of attributes
from the instance, but with a property on each attribute to indicate
whether it came from the definition or the instance. It is really just
a way of accessing two separate lists of attributes attached to two
different language elements, both from the same call. In this case,
you should get back the same attribute twice, once with the vpiDefAttribute
property, and once without.
This was very deliberate. There was discussion of having one of the
attributes automatically override the other. However, it was not entirely
clear which should win. People were able to come up with different
situations that called for each. By making both attributes available to
the PLI, the application can implement its own overriding mechanism
whichever way makes sense for the attribute in question.
So the "same name" case is the same as the "different name" case below.
> 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.
If an order is defined, then this order should probably be defined too.
It may not be strictly necessary, since the application can check the
property and separate the single list into two ordered lists for itself.
However, it shouldn't cost anything to guarantee an order, and it might
speed an application up. (For example, if the ones from the definition come
first, and that is what the application wants to get, it can stop iterating
when it reaches the first non-definition attribute. Or if it wants to have
the instance attribute override the definition ones, it could just run
through them in order and keep the last value it sees, instead of keeping
track of both and resolving them at the end.)
I do think that another clarification is needed. In the case of
(* foo = 0, bar = 0, foo = 1 *), should the attribute foo be returned
before or after bar? When the parser finds the duplicate, it could either
throw the first one away, or just replace the value. So an implementation
might do it either way if there is no clarification.
>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.
OK, I'll accept your expert input on the PLI issue, and agree with you on
the rest also.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2b28 : Mon Sep 02 2002 - 12:43:54 PDT