From: Pragmatic C Software (sjmeyer@pragmatic-c.com)
Date: Wed Jan 23 2002 - 17:29:45 PST
Precedence: bulk
I implemented attributes (actually only a subset are passed to PLI currently)
in Cver early last year and interpreted the LRM language somewhat
differently. I guess the exact attribute behavior in PLI needs to be
defined better. Also, I think allowing duplicate attributes is a bad idea.
It causes source order problems similar to those that occur with defparams.
Also, there is an application of Cver that uses attributes as kind of
special parameter so it is very important to be able to search attributes
fast and duplicat attributes make this problematic.
Quoting Dennis Marsa (drm@xilinx.com):
> Precedence: bulk
>
> Steve,
>
> Thanks for taking the time to put together such a detailed reply to my
> questions.
>
> I have to apologize for not taking the time to search the BTF archives
> on the topic of attibutes to read what has been discussed there. In my
> defense, at the time I was putting my questions together the BTF search
> function was not working (for me at least). However, I could have been
> more patient before sending out my questions.
>
> Now that I've read some of the old discussions on attributes and your
> reply, I have a better understanding of the motivations behind how
> attributes were defined.
>
> > >I am thinking of these issues in terms of extracting attribute
> > >information using the VPI interface.
> >
> > VPI should give access to the raw attributes attached in the design
> > and leave it up to the application to do any further processing.
> >
> > If you are the one responsible for implementing the VPI interface,
> > this means one less thing you have to worry about implementing.
> >
> > >1. Module Declaration and Module Instantiation Attributes
> > >---------------------------------------------------------
> > >
> > > According to the BNF in 1364-2001, attributes can be attached to both
> > > a module declaration and a module instantiation.
> >
> > VPI provides separate access to the attributes attached to each. That
> > is all it has to do.
>
> But this is not the case.
>
> VPI does *not* provide separate access to the attributes of module
> declarations and module instantiations.
>
> Since VPI is a post-elaboration interface, all module instantiations
> have been bound to their module declaration. The VPI interface defines
> a "Module" object (defined by section 26.6.1) for each module instanced
> in a design. The VPI "Module" object essentially represents both the
> module declaration and instantiation.
>
> >From this "Module" object, information from the module declaration is
> available, such as its ports, internal signals, logic and behavior. In
> additional, information from the module instantiation is also available
> from the same "Module" object, such as its port connections, file/line
> information and parameter overrides.
>
> But, only *one* set of attributes is available from a VPI "Module"
> object.
Since in vpi_ vpiModule object is an instance not a module definition
and there is no way to acces the module definition from vpi_ (it probably
doesn't make sense anyway because of structural pound param and defparms),
I assumed the rule that attributes attaches to instances over-ride the
same attribute name attached to instance. I interpreted the defined attribute
to determine source of the one non repeated attribute; not to distinguish
duplicates.
>
> So, two sets of attributes can be specified in the source, one set at
> the module declaration, and another set at the module instantiation, but
> only one set is available from VPI.
>
> To resolve this, one would have to either define some rule for combining
> the two sets of attributes, or extend VPI to allow independent access to
> each set.
I think the instance over-rides is not really a vpi_ interpretation but
is needed since module type definitions really do not exsist after
elaboration.
>
> > During the standardization process, people suggested uses for
> > attributes attached to all sorts of things. As a result, they got
> > extended to lots of new objects late in the process. The VPI portion
> > of the standard may not have stayed in sync with the language portion.
> > If I knew more about the VPI stuff, I might be able to answer your
> > question, or recognize such an error in the standard. I'll try
> > consulting someone who knows more about it.
Yes. I think the the vpi diagram 26.6.42 was intended to mean any object
and allowed particular tools to allow attributes as extension on other
objexts.
>
> Yes, it seems the attribute object diagram in section 26.6.42 is missing
> several objects that can hold attributes according to the BNF. Notably,
>
> "IODecl"
> "ContAssign"
> "DefParam"
> "Parameter"
I interpreted adding attribute to IODecl meant add it to port not IODecl
statement and same for Parameter definition statement. I think this
is needed since vpi_ access needs to be to post elaboration design where
multiple paraterm definitions and def params may over-ride each other.
Therefore I do not think attributes that appear in source on the declaration
should be in list, i.e. they should go on object.
>
> > >3. Port Connection Attributes
> > >-----------------------------
> > >
> > > According to the BNF in 1364-2001, attributes can be attached to individual
> > > port connections in module/udp/primitive instantiations.
> >
> > And there is presumably a way to access them, independently from any other
> > attribute.
>
> Yes, the port connection information is available via the "Port" object.
> But, "Port" objects provide access to information from other syntactic
> elements as well, several of which can also have attributes attached.
> But, as with "Module" objects, "Port" objects provide access to only
> *one* set of attributes.
Again if attribute is attached to post elaboration object, instance
connection attribute is attached to vpiExpr meta object (object class),
and port attribute is attached to port object. vpiHighConn or vpiLowConn
allow accessing both givin one of the objects.
>
> > I don't know whether anyone had a specific purpose in mind for attaching
> > attributes to defparams. Note that if somebody wanted to use a defparam
> > mechanism to control an attribute attached to a parameter, there is already
> > a way to do that without any kind of attribute overrides.
> >
> > module top;
> > defparam top.A.a = 123;
> > defparam top.A.a_override_attr = 1;
> > modA A();
> > endmodule
> >
> > module modA;
> > parameter a_override_attr = 0;
> > (* override = a_override_attr; *) parameter a = 1;
> > endmodule
> >
> > Since attribute definitions can be any constant expression, they can
> > include parameter values, which can be defparam'ed from elsewhere.
> >
> > This effectively allows the Verilog code to define its own "propagation"
> > of attribute values via the parameter value propagation mechanisms.
I agree. I thought defparams were being deprecated.
>
> I now agree this is fine. Separate access to attributes attached to the
> parameter, and to the defparam are available, so this is not an issue in
> my mind anymore.
>
> > >5. Parameter Assign Attributes
> > >------------------------------
> > >
> > > According to the BNF in 1364-2001, attributes can be attached to parameter
> > > assignments in module instantiations.
> > >
> > > module top;
> > > modA #((* override *) 123) A();
> > > endmodule
> > >
> > > module modA;
> > > parameter a = 1;
> > > endmodule
> > >
> > > QUESTION 1: Should the attribute "override" be attached to or
> > > combined with the attributes of the parameter "a" in instance "A"
> > > of module "modA"? Or should "override" only appear as an
> > > attribute of the parameter assignment?
> >
> > You can undoubtedly predict my answer by now.
>
> As with defparam's, separate access to each set of attributes is
> available, so no longer an issue for me.
I think attribute override needs to go on the pound parameter vpiExpr
class object to be consistent with other attachments to expressions.
>
> > >6. Generate Attributes
> > >----------------------
> > >
> > > According to the BNF in 1364-2001, attributes can be attached to
> > > a "generate-endgenerate" structure, but not to generate items within
> > > that structure.
> > >
> > > QUESTION 1: What happens to the attributes attached generate/endgenerate
> > > structure during the design elaboration process? The
> > > generate/endgenerate structure will be replaced by its expansion in
> > > the elaborated design.
> >
> > If VPI does not provide access to the generate/endgenerate structure, then
> > there was no point in attaching attributes to it. This may be one of those
> > mismatches between the language and VPI sections I mentioned.
> >
> > As far as attachment to generate items, can't most of those items already
> > have attributes attached? E.g. a module instantiation can have an attribute
> > attached to it, whether it is inside a generate or not. Allowing it to have
> > an attribute attached to it as a module instantiation and as a generate
> > item would create an ambiguous grammar. How could you tell which one the
> > attribute is attached to, when the syntax is identical?
>
> Yes, you are right, individual generate items can have attributes
> attached. I missed that.
>
> The issue remaining is what happens to any attributes attached to the
> "generate" structure itself?
I am not sure how this should be handled since generate does not exist
in the elaborated design.
-- Steve Meyer sjmeyer@pragmatic-c.com
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:34 PDT
and
sponsored by Boyd Technology, Inc.