From: Pragmatic C Software (sjmeyer@pragmatic-c.com)
Date: Wed Oct 31 2001 - 18:05:20 PST
Precedence: bulk
I have implemented attributes that attche to most of the major constructs
and ended up with a rather complex algorithm but I think this is what
users want.
First, in order to be able to attach attributes to correct construct,
I needed to build syntax tree during pass one and evaluate and assign
attribute to constructs at start of pass 2 when arrays of gates and
instances are elaborated (this may be needed because of recursive
descent parsing method). Therefore, parameters are allowed but they
are "fixed" at same time array of instance range determining parameters
are fixed (need to be able to build instance tree). This allows
parameters to be used but attribute parameter value is not post
defparam or pound param value.
I think idea of attaching attributes to HDL constructs is very good
since it solves the "region" problems that occur with directives
(also with ifdefs).
Main advantage of allowing parameters is that PLI tools during
simulation can either choose to use the compile time value by
getting value of attribute or can calculate the post elaboration value
by re-evaluating the expressions in the PLI.
Users definitely want to be able to attach attributes to variables
that they can turn on and off and I think there is no better
alternative that parameter expressions as attribute value.
/Steve
Quoting J. Bhasker (jbhasker@cadence.com):
> Precedence: bulk
>
> Paul:
>
> Just a comment: Attributes are not free standing, i.e. they are not a
> statement
> by themselves, but are always associated with a statement/module/expression.
> So trying
> to implement synthesis_on/off using attributes would limit its flexibility
> as compared
> to where all you can place the on/off directives today.
>
> - bhasker
>
> --
>
> J. Bhasker
> Cadence Design Systems
> 7535 Windsor Drive, Suite A200, Allentown, PA 18195
> (610) 398-6312, (610) 530-7985(fax), jbhasker@cadence.com
>
>
> -----Original Message-----
> From: owner-btf@boyd.com [mailto:owner-btf@boyd.com]On Behalf Of Paul
> Graham
> Sent: Wednesday, October 24, 2001 11:26 AM
> To: stuart@sutherland-hdl.com
> Cc: btf@boyd.com
> Subject: Re: Attributes and constant expressions
>
>
> Precedence: bulk
>
> > I believe the standard very clealy states that a genvar is only valid at
> > elaboration time. It therefore would have no value during simulation
> time,
> > and therefore should not be a legal expression in an attribute.
>
> No, a reference to a genvar results in a value at simulation time.
> Otherwise, the following would make no sense:
>
> genvar i;
> generate for (i = 0; i < 8; i = i + 1)
> begin : blah
> assign q[i] = d[i];
> end
> endgenerate
>
> When the simulator executes, there must be some meaning for q[i] and d[i].
> While the genvar data structure may exist only during elaboration, its value
> remains for simulation. So it is a perfectly good, simulation-time
> constant.
>
> My original question was really to find out whether attributes were intended
> to be more like preprocessor-style directives or vhdl attributes.
> Preprocessor directives in C support only the simplest of expressions, while
> vhdl attributes can have any complex constant value (including calls to
> constant functions). It seems the intent is be like vhdl.
>
> I also was wondering how to implement attributes in my parser. If
> attributes are simple, preprocessor-like directives, then a simple data
> structure holding, say, a string and integer would be sufficient for the
> parser to store an attribute's value.
>
> Also, since attributes are intended in part to provide a vendor-independent
> way of specifying synthesis directives, I wondered how some commonly used
> synthesis directives could be specified using attributes. One very common
> directive is:
>
> // ambit synthesis off
> ...
> // ambit synthesis on
>
> Suppose this were translated into an attribute:
>
> (* synthesis = 0 *)
> ...
> (* synthesis = 1 *)
>
> Now suppose that the expression depends on a parameter. Then synthesis
> could be enabled or disabled in a module based on some defparam in another
> module. Thinking about this gave me a headache.
>
> Paul
>
-- Steve Meyer sjmeyer@pragmatic-c.com
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:48 PDT
and
sponsored by Boyd Technology, Inc.