Re: Enhancement: Dynamic Values on attributes.

From: Steven Sharp (sharp@cadence.com)
Date: Mon Nov 03 2003 - 17:56:25 PST

  • Next message: Steven Sharp: "Re: Enhancement: Dynamic Values on attributes."

    Krishna,

    While you only need this functionality for this one particular use, it is
    easy to imagine that it might be useful in other situations as well. If
    we are going to add something like this, it makes sense to try to make it
    as useful as possible in return for the effort.

    While this could just be restricted to attribute values, it could also
    be useful to allow it for parameter values as well. Even in your attribute
    situation, someone might want to construct one of these attribute strings
    with $strcat and pass the value into a parameter using a parameter override
    on the instantiation, so that they can use that parameter value in setting
    an attribute inside the module.

    The main reason I originally proposed allowing constant expressions to be
    used for attributes (instead of just simple constant literals) is so that
    users could use parameters in attribute values. This allows them to use
    the existing mechanisms for parameter propagation to propagate values to be
    used for attributes. The fact that this also allows genvars to be used to
    set different attribute values for each instance was an unforeseen benefit
    of using good design principles. Both parameters and genvars can be used
    in constant expressions, and this is orthogonal to whether the constant
    expression is being used to set a parameter or attribute value.

    In the same way, if this new functionality is allowed in constant expressions
    for attribute values, it should be allowed for parameter values as well (and
    in any other situation where constant expressions are allowed). There might
    be unforeseen uses for this in the future. Orthogonality is generally good.

    The next question is whether it should be usable in non-constant expressions.
    Constant expressions are currently a subset of normal expressions, and it
    would be hard to justify changing that. Nor is it necessary. Avoiding the
    problems with determining the width of the result does not require that it
    appear only in constant expressions. It only requires that the arguments to
    the system function be constants, which is less restrictive.

    Users may still find it too restrictive. They may want to have this same
    functionality with variables, and be upset if it isn't available. But once
    you define it in a way that works only with constants, you can't easily
    change it to work with variables. It may be better to define it so that
    it works reasonably with variables from the start. This is a tradeoff that
    needs to be considered.

    How picky are the back-end tools you are producing these values for? Will
    they accept leading spaces or zeroes on the numbers in the strings? While
    I suggested that NUL characters would be used to pad the results up to the
    maximum width (determined at compile time), that is not the only option.
    If we think about printing values into strings, leading spaces or "0"
    characters naturally come to mind for padding up to the field width. The
    back-end tools may be able to parse such strings easily. If they use
    sscanf() or something similar, they will still extract the same numerical
    value.

    Steven Sharp
    sharp@cadence.com

    This archive was generated by hypermail 2.1.4 : Mon Nov 03 2003 - 17:49:49 PST and
    sponsored by Boyd Technology, Inc.