Re: Enhancement: Dynamic Values on attributes.

From: Krishna Garlapati (krishna@synplicity.com)
Date: Fri Oct 31 2003 - 15:13:20 PST

  • Next message: Shalom Bresticker: "Re: errata/498: enhanement system function/task to extract timescale info to variables"

    Steven,

    You raise some valid points. I agree that the naming for $strcat is
    confusing and it
    can be discussed and agreed upon to which I have not any issue. The
    issue here
    is to provide functionality to something that is very commonly used in
    FPGA tools to
    send "messages" to the backend tools for which there exists no easy
    solution.

    As I indicated in my earlier email, the arguments to $strcat should be
    compile time
    constants (and hence a built-in constant function). So I think you will
    agree with me that
    determining the size is not a big issue.

    As far as the functionality of $strcat goes, currently out tools allow
    the usage of it only
    within attributes. I think it is perfectly if the LRM imposes the same
    restriction.

    The current implementation is something the users need now and Verilog
    lacked.
    We provided a workable solution that gets the job done. I think it would
    be great
    if Verilog can provide the support natively.

    Thanks,

    Steven Sharp wrote:

    >>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
    >
    >
    >
    >
    > 

    -- 
- Krishna Garlapati, Synplicity Inc. (408)215-6152

    This archive was generated by hypermail 2.1.4 : Fri Oct 31 2003 - 15:06:46 PST and
    sponsored by Boyd Technology, Inc.