Re: Enhancement: Dynamic Values on attributes.

From: Steven Sharp (sharp@cadence.com)
Date: Fri Oct 31 2003 - 13:47:32 PST

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

    >The vendor's backend tool expects a single attribute in a string form and
    >ignores everything else. I agree with you that using multiple Vlog-2001
    >style attributes can achieve the requested functionality but it does not
    >fulfill the
    >purpose.

    As I understand it now, the problem is still due to a poor choice of
    attributes in the backend tool. But since it is not your tool you can't
    do anything about it, and you need a way to work around the problem. So
    I will accept that there is a real problem that needs to be solved here.

    I have some further comments on the proposed solution.

    I don't think that $strcat is a good choice for a name for this
    functionality. The name matches the standard C library function strcat(),
    but the functionality is significantly different. The strcat() function
    concatenates strings together. Your proposed $strcat concatenates string
    literals, but "prints" other values in (apparently) decimal format into
    a string and concatenates those strings. This is not the same, which could
    be very misleading. If someone set a parameter to a string value, and then
    used the parameter in your $strcat, they would not get that string value
    concatenated. Instead they would get the numerical equivalent of that string
    converted into a string of decimal digits, which look nothing like the
    original string value. For example:

      parameter p = "a";
      parameter q = $strcat(p,"b");
      
    This would not set q to "ab" as you would expect for a function with the
    same name as a C routine that concatenates strings. Instead it would set
    q to "97b", because the ASCII for "a" is 97, so the numerical value of p
    is 97.

    The proposed function is also not very general. You have arbitrarily
    decided that non-string-literal values should be converted to strings using
    a decimal format. This may serve your immediate need, but may not cover
    other similar situations. What happens when someone wants to pass in a
    mix of strings and numbers in parameters, and get the numbers converted
    into strings, but the strings kept intact? This really calls for a format
    argument, instead of converting all values using a decimal format. Then
    you could use %s to keep a value as a string, and %d to convert numerical
    values to decimal, and so forth.

    In addition to these issues, I see a fundamental problem here. What is
    the width of the expression containing the $strcat call? All expressions
    in Verilog must have a width that can be determined at compile time, and
    all existing constructs are designed to satisfy that requirement. You
    won't find this documented in the LRM because the user doesn't need to
    know it. The language has been designed so that it is always true. But
    any new constructs need to maintain this requirement.

    With this $strcat call, you presumably wanted the width to be exactly
    the minimum number of bits required to represent the resulting string.
    If all of the arguments are compile-time constants, then this is possible.
    The width can be determined (rather inconveniently) by actually evaluating
    the function and seeing what width was needed. But surely this new system
    function would not be restricted to constant values as arguments? And if
    it isn't, then how do you determine what the width of the result will be
    at compile time? The best suggestion I can come up with is to determine
    the maximum width that could be required for the result, based on the
    widths of the arguments (the same way that $display determines how much
    space to print a number in). Then you would have to produce a string of
    that width regardless of the actual values, padding the upper bytes with
    zero bytes as usual for extension to greater width.

    >""Printing" a numerical value into a string form is a complex operation,"
    >
    >I am wondering why?? I dont see a big problem here or may be I am
    >missing something.

    I'm not saying that it can't be done. I am saying that it is complex
    enough that you can't do it easily in an expression. Nor would most
    users want to have to write a Verilog function capable of doing it. That
    is exactly why you are suggesting that it be done by a built-in system
    function.

    Steven Sharp
    sharp@cadence.com

    This archive was generated by hypermail 2.1.4 : Fri Oct 31 2003 - 13:40:52 PST and
    sponsored by Boyd Technology, Inc.