Re: Enhancement: Dynamic Values on attributes.

From: Krishna Garlapati (krishna@synplicity.com)
Date: Thu Oct 30 2003 - 18:54:24 PST

  • Next message: Adam Krolnik: "Re: Enhancement: Dynamic Values on attributes."

    Apart from being stuck since $swrite is a task, there is another issue.
    The syntax for $swrite needs to provide an output register of proper
    size to which the resultant string is written. Our proposal does not
    need this
    since the output string "variable" is generated internally of
    appropriate size.

    >However you say that the vendors tool wants a single attribute in a
    >string; so this leads be to believer if there was a $strcat, it would
    >not work:

    I am not sure why. For,

    parameter [31:0] xloc = 1,
              [31:0] yloc = 1,
              [10*8:1] size = "small";

    (* placement=$strcat(xloc,yloc,size) *) dff ff1 (q,d,clk)

    $strcat returns the string "11small" that gets assigned to placement and is
    carried on the instance ff1.

    I think the constant function example you cited will work. $strcat is
    very flexible
    since the users dont need to write a seperate constant function and
    allocate appropriate
    sizes for output strings. Its also pretty easy for the Verilog tool to
    do this since all the
    parameter sizes can (should) be determined at compile time.

    Michael McNamara wrote:

    >So it seems that $swrite almost fits the bill, but because it is a
    >task rather than a function, one is stuck.
    >
    >However you say that the vendors tool wants a single attribute in a
    >string; so this leads be to believer if there was a $strcat, it would
    >not work:
    >
    >dff ff1 (q,d,clk) (* placement=$strcat(xloc,yloc,size) *)
    >
    >
    >Note of course, that you don't need it to be a system function,
    >however it may make it easier, as one could define scat_loc as a user
    >constant function, which calls $swrite to do the work:
    >
    >function [80*8:1] scat_loc( input [31:0] xloc, yloc, size)
    > begin
    > $swrite(scat,"%d_%d_%s",xloc,yloc,size);
    > end
    >endfunction
    >
    >and then give the parameters:
    >
    >parameter [31:0] xloc = 1,
    > [31:0] yloc = 1,
    > [10*8:1] size = "small";
    >
    >and the instantiation:
    >
    >dff ff1 (q,d,clk) (* placement=scat_loc(xloc,yloc,size) *)
    >
    >Or does the tool instead parse the verilog, and hence these constant
    >functions will not be called?
    >
    >
    >dff ff1 (q,d,clk) (* placement=scat_loc(xloc,yloc,size) *)
    >-- On Oct 30 2003 at 16:36, Krishna Garlapati sent a message:
    > > To: sharp@cadence.com, btf@boyd.com
    > > Subject: "Re: Enhancement: Dynamic Values on attributes."
    > >
    > > I guess my explanation for this request was not very clear. FPGA designers
    > > use these attributes primarily to pass custom information (like location,
    > > mapping methods, types etc) to the vendor backend.
    > >
    > > 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.
    > >
    > > My request is to simply provide a function that can take in a bunch
    > > of strings and constant expressions as parameters and return a
    > > string, which is the concatenated version that contains all the
    > > string parameters (as is) and evaluated constant expressions. I
    > > also think implementing this is pretty very straightforward.
    > >
    > > We have implemented attributes for VLog-2001 and I don't think
    > > there is a single system function that can realize this. A good
    > > percentage of our users are already using the $strcat and we think
    > > it would be a good idea to make it into the standard for
    > > compatibility issues.
    > >
    > > "From your example, it appears that "xc_rloc" takes a string that
    > > holds a row and column position encoded by strings of digits after
    > > "R" and "C" (I'll ignore the ".S" part, since I didn't understand
    > > what it was). You could do the same thing easily in Verilog-2001
    > > by changing this to two attributes, "xc_rloc_R" and "xc_rloc_C",
    > > which take the row and column directly as numerical values instead
    > > of converted to strings."
    > >
    > > This is not acceptable to the users for the reasons I listed above.
    > >
    > > ""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.
    > >
    > > --
    > > - Krishna Garlapati, Synplicity Inc. (408)215-6152
    > >
    >
    >
    >
    > 

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

    This archive was generated by hypermail 2.1.4 : Thu Oct 30 2003 - 18:47:47 PST and
    sponsored by Boyd Technology, Inc.