ISSUE 502

Add Proposal  Add Analysis  Edit Class, Environment, or Release
Number 502
Category enhancement
Synopsis Dynamic Values on attributes
State open
Class enhancement
Arrival-DateNov 05 2003
Originator Shalom.Bresticker@motorola.com
Release 2001b
Description
This mail is to enter this enhancement request into the database.

---------- Forwarded message ----------
Date: Thu, 30 Oct 2003 14:25:33 -0800
From: Krishna Garlapati <krishna@synplicity.com>
To: btf@boyd.com
Subject: Enhancement: Dynamic Values on attributes.


Frequently, our users ask for a method by which attributes can be created
dynamically. Basically they want a convenient way to associate new values
to attributes that are a combination of strings and compile time constants.
This usage is typically associated with generate statements and I have
an example in the end.

The existing $swrite can be used, but is not very intuitive. To achieve
this we
have implemented a system function called $strcat in our Verilog Compiler
and would like it to make into the 1364 standard.

The format of this function is as follows:
*
Format*

$strcat(string (or) const [, string (or) const]);
returns a string

*Parameters*

string -> any compile time string
const -> any compile time constant

*Return value*

a concatenated string that consists of all the evaluated parameters

*Example:*


generate for(i=0; i <= 7; i = i+1)
begin: my_reg
(* xc_rloc=$strcat("R",i,"C0.S0"),xc_uset="SET1" *) FDE flip_flop
(.D(d[i]), .CE(ce),.C(clk),.Q(qb[i]));
// myreg0.flip_flop gets an attribute xc_rloc = "R0C0.S0"
// myreg0.flip_flop gets xc_rloc = "R1C0.S0"
// and so on...
end
endgenerate

Thanks,

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


Fix

Unknown
Audit-Trail
From: Shalom.Bresticker@motorola.com
To: btf-bugs@boyd.com
Cc:
Subject: Re: enhancement/502: Dynamic Values on attributes
Date: Wed, 5 Nov 2003 12:40:28 +0200 (IST)

This mail is to enter the entire dicussion on this issue into the
database. Please send further discussion to btf-bugs@boyd.com with
subject "enhancement/502".

Thanks,
Shalom


Date: Thu, 30 Oct 2003 14:25:33 -0800
From: Krishna Garlapati <krishna@synplicity.com>
Subject: Enhancement: Dynamic Values on attributes.

Frequently, our users ask for a method by which attributes can be created
dynamically. Basically they want a convenient way to associate new values
to attributes that are a combination of strings and compile time constants.
This usage is typically associated with generate statements and I have
an example in the end.

The existing $swrite can be used, but is not very intuitive. To achieve this we
have implemented a system function called $strcat in our Verilog Compiler
and would like it to make into the 1364 standard.

The format of this function is as follows:

*Format*

$strcat(string (or) const [, string (or) const]);

returns a string

*Parameters*

string -> any compile time string
const -> any compile time constant

*Return value*

a concatenated string that consists of all the evaluated parameters

*Example:*

generate for(i=0; i <= 7; i = i+1)
begin: my_reg

(* xc_rloc=$strcat("R",i,"C0.S0"),xc_uset="SET1" *)
FDE flip_flop (.D(d[i]), .CE(ce),.C(clk),.Q(qb[i]));

// myreg0.flip_flop gets an attribute xc_rloc = "R0C0.S0"
// myreg0.flip_flop gets xc_rloc = "R1C0.S0"
// and so on...

end
endgenerate


Date: Thu, 30 Oct 2003 18:31:18 -0500 (EST)
From: Steven Sharp <sharp@cadence.com>

In Verilog-2001, attribute values can already be set using constant
expressions. This allows them to be defined in terms of compile time
constants such as parameters and genvars. They can even use constant
functions to compute things that are not easily done with expressions.
This would appear to provide the basic functionality that you are
talking about. I am not aware of any tools that support anything but
simple constants for attribute values (and some apparently only accept
strings), but that is not the fault of the 2001 standard.

Beyond this, what you are proposing effectively involves two extensions.
The first is to allow certain system functions to be used in constant
expressions. This is already mentioned in a couple of the proposals
that I have made. This seems reasonable for system functions that are
"pure" functions.

The second is a new standard system function called $strcat, which works
much like $swrite but is a function instead of a task (so it could be
used in constant expressions).

While neither of these is unreasonable, I don't think that the solution
to your particular problem requires them. The reason it appears to be
needed is that the genvars or parameters that you want to use to set
the values are numerical values. But your tool has defined a set of
attributes that it expects to be set using string values, with numbers
encoded as sequences of characters. "Printing" a numerical value into
a string form is a complex operation, and your proposal is to do this
with a system function.

But there is a simpler solution to this. The only reason for this
complex operation is that you chose to define the attributes for your
tool to expect strings instead of numerical values. It just isn't a
very convenient format for values you want to compute numerically. If
you redefined the attributes to be numerical values instead, then
this would all become simple to do in Verilog-2001. If you need to
maintain backward compatibility, you could accept either the old
attribute values which are strings, or the new ones which are numbers.

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. Then your example would become

generate for(i=0; i <= 7; i = i+1)
begin: my_reg

(* xc_rloc_R=i, xc_rloc_C=0, xc_uset="SET1" *)
FDE flip_flop (.D(d[i]), .CE(ce),.C(clk),.Q(qb[i]));

// myreg0.flip_flop gets an attribute xc_rloc_R = 0
// myreg0.flip_flop gets xc_rloc_R = 1
// and so on...

end
endgenerate

This works fine with the existing Verilog-2001 language. You just
have to implement attributes fully as defined, and then change the
attributes that your tool uses.

It is possible that I am missing something here. Someone recently
posted a question of how to do something like this in comp.lang.verilog.
I answered with a description of 2001 attributes, and how the tool
vendor could redefine their attributes to make this work, and I got
flamed for my efforts.


Date: Thu, 30 Oct 2003 16:36:09 -0800
From: Krishna Garlapati <krishna@synplicity.com>

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.


Date: Fri, 31 Oct 2003 10:46:31 -0800
From: Michael McNamara <mac@verisity.com>

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?


Date: Thu, 30 Oct 2003 18:54:24 -0800
From: Krishna Garlapati <krishna@synplicity.com>

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 don't need to write a seperate
constant function and allocate appropriate sizes for output strings.
It's also pretty easy for the Verilog tool to do this since all the
parameter sizes can (should) be determined at compile time.


Date: Fri, 31 Oct 2003 09:51:48 -0600
From: Adam Krolnik <krolnik@lsil.com>

It's too bad one can't write

(* xc_rloc={"R",i,"C0.S0"}, xc_uset="SET1" *)

and get the desired behavior.

Though, it seems that SystemVerilog, with their string type, can do this.

[* Table 3-2 that describes string concatenation is not very clear on
cases like this.]

If "i" was only expected to be a single character, one can today write:

parameter astr = {"R",8'h30 + i,"C0.S0"}; // i=2 => astr=R2C0.S0

I.e.

module test;

parameter astr = {"R",8'h30 + 8'd2,"C0.S0"};

//(* astr = {"R",8'h30 + 8'd2,"C0.S0"} *)
(* astr = astr *)
reg adam;

initial $display("astr parameter is %s.\n", astr);

endmodule


Date: Fri, 31 Oct 2003 11:04:03 -0800
From: Krishna Garlapati <krishna@synplicity.com>

Looks like System Verilog does it nicely. But how does the tool
figure out that you are dealing with strings in parameter unless
the declaration was :

parameter string astr = {"R",8'h30 + i,"C0.S0"}; // i=2 => astr=R2C0.S0


Date: Fri, 31 Oct 2003 13:11:35 -0600
From: Adam Krolnik <krolnik@lsil.com>

>Looks like System Verilog does it nicely. But how does the tool
>figure out that you are dealing with strings in parameter unless

It's not clear as to what is supposed to happen. I will ask...


Date: Fri, 31 Oct 2003 16:47:32 -0500 (EST)
From: Steven Sharp <sharp@cadence.com>

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


Date: Fri, 31 Oct 2003 16:49:17 -0500 (EST)
From: Steven Sharp <sharp@cadence.com>

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

Constant functions are not allowed to call system tasks (or if they
do, the task is ignored).


Date: Fri, 31 Oct 2003 16:53:33 -0500 (EST)
From: Steven Sharp <sharp@cadence.com>

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

Presumably Krishna means that their tool evaluates the attribute and
prints out the value in its output, not the original expression. So
the output would be the string, not the $strcat expression.

Note that their tool is assuming that these things are strings. There
is no real distinction between a string and a number in Verilog. They
are both just vector values.


Date: Fri, 31 Oct 2003 15:13:20 -0800
From: Krishna Garlapati <krishna@synplicity.com>

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


Date: Mon, 03 Nov 2003 08:29:33 -0600
From: Adam Krolnik <krolnik@lsil.com>

>But how does the tool figure out that you are dealing with strings in
>parameter unless the declaration was :

>parameter string astr = {"R",8'h30 + i,"C0.S0"}; // i=2 => astr=R2C0.S0

Each element is sized and then concatenated, just like verilog 1995.
This line (below) is verilog-1995. You can do this today in VCS.
The program I included compiles in VCS with the +v2k option
for attributes.

parameter astr = {"R",8'h30 + i,"C0.S0"}; // i=2 => astr=R2C0.S0


module test;

parameter astr = {"R",8'h30 + 8'd2,"C0.S0"};
//(* astr = {"R",8'h30 + 8'd2,"C0.S0"} *)
(* astr = astr *)
reg adam;
initial $display("astr parameter is %s.\n", astr);

endmodule

% vcs catstr.v
...
Parsing design file '/tmp/catstr.v'
Top Level Modules:
test
No TimeScale specified
1 unique modules to generate
Invoking loader...
Chronologic VCS simulator copyright 1991-2003
Contains Synopsys proprietary information.
Compiler version 7.0.1; Runtime version 7.0.1; Nov 3 08:27 2003

astr parameter is R2C0.S0.


Date: Mon, 03 Nov 2003 11:02:11 -0800
From: Krishna Garlapati <krishna@synplicity.com>

Your example works for direct connstants (like 1+2) within parameters.
But I don't think it will, when used in conjunction with variables that
are constants at compile time (like genvars).

genvar i;

generate for(i=0; i<=7; i = i + 1)...

parameter xc_rloc = {"R", i, "C0.S0"};
(* xc_rloc = xc_rloc *) foo bar(..port connections..)
..
..
endgenerate


In this example it is not clear which value of i would be binded to the the
parameter declaration for xc_rloc. Moreover, I think parameter declarations
are illegal within generates, they can only be overrided.

I still think there is a need for a builtin constant function in Verilog
that produces a concatenated string output on compile time constant values.


Date: Mon, 03 Nov 2003 13:39:28 -0600
From: Adam Krolnik <krolnik@lsil.com>

You don't need to parameter - I used it to view/test the results.
You should be able to say:

generate for(i=0; i<=7; i = i + 1)...

(* xc_rloc = {"R", i, "C0.S0"} *) foo bar(..port connections..)

As an attribute accepts a constant expression. I don't have a way to read
attributes from the PLI yet...

I do see a usefulness in creating a string of multiple arguments.


Date: Mon, 3 Nov 2003 20:56:25 -0500 (EST)
From: Steven Sharp <sharp@cadence.com>

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.


Date: Mon, 3 Nov 2003 21:24:15 -0500 (EST)
From: Steven Sharp <sharp@cadence.com>

I had another thought on the form of the system function.

While trying to explain why $strcat was different from the C strcat, I
was thinking that it was sort of like a combination of the C strcat with
a C itoa function. Except that there isn't actually a C itoa function
(integer to ASCII), only a C atoi function (ASCII to integer), which does
the reverse.

Then Adam started discussing the use of Verilog vector concatenation to
do the string concatenation part, with a 1-character-long conversion
to string that only handles values between 0 and 9. Again, it is the
conversion function that is missing, not the concatenation capability.

So instead of a $strcat that does the conversion and concatenation both,
perhaps it would be better to have a $itoa or $itos (integer to string)
function, and use the existing concatenation operator for the concatenation
part. This would fit in with the existing $itor and $rtoi conversion
functions. The naming convention could be extended by having a family
of functions with a base specifier at the end of the name, like the
$display family of tasks (and $readmemb and $readmemh). I must admit
that a name like $itosb is pretty ugly though.

One reason I find this attractive is that the existing system functions
that could be allowed in constant expressions are all classified as
conversion functions. Having this new system function be a conversion
function also would keep things neat and make it easy to describe what
system functions were allowed in constant expressions.

Note that this does not help with the width problem at all. This new
system function would still need to be defined in a way that ensured
that the result had a constant width known at compile time. It would
still require some kind of padding. And if the padding were with NUL
characters, and the result were used in a concatenation, the NULs would
end up in the middle of the resulting vector. This might be even less
convenient to deal with.


Date: Tue, 04 Nov 2003 07:35:17 +0200
From: Shalom Bresticker <Shalom.Bresticker@motorola.com>

$itos and $stoi would be very useful.
We have often had need for such.


Date: Tue, 4 Nov 2003 16:11:04 -0500 (EST)
From: Steven Sharp <sharp@cadence.com>

>$itos and $stoi would be very useful.
>We have often had need for such.

I assume that most of the need for $itos and $stoi can be met by the
Verilog-2001 system tasks $swrite and $sscanf with %d formats, though
they may not be as convenient as function versions in some situations.

I don't know if you were reading the details of the earlier discussion,
but there are some issues with function versions. All operands in
Verilog expressions must have known widths at compile time, including
system functions. This width can depend on things known at compile
time (such as the width of the arguments), but not on things that are
not known at compile time (such as the values of variables). So if you
want $itos to accept variable arguments and be able to produce the
correct string for the maximum possible value of the arguments, the
result must be as wide as that maximum possible value needs. And that
means that it will be that wide even for smaller values.

For example, a 32-bit signed integer requires 10 decimal digits to
represent the maximum value, 11 if you allow for a negative sign. That
means an 80 or 88 bit wide vector result. Even if the argument turns out
to be 1, the result would still be 88 bits wide. The lowest byte would
presumably be the ASCII character "1", but what should be used for the
upper bytes? The obvious candidates are:

- zero-extend the value with zero bits (creating NUL bytes). This is
what you would get if you assigned the shorter string "1" to the larger
80 or 88 bit wide vector.

- zero-pad the numeric field with "0" characters (e.g. "00000000001"
or maybe " 00000000001" or "+00000000001" if we had to leave space for
a negative sign). The first is how binary or hex values get printed
by $display. There is no example of the signed situations since binary
and hex formats print as unsigned and decimal format can print a sign
but doesn't print leading zeros. Some version of this might work for
Krishna's back-end tools, since they may be able to parse numbers with
leading zeros.

- pad with spaces (e.g. " 1"). This is how decimal values are
printed by $display.


Date: Tue, 04 Nov 2003 14:17:11 -0800
From: Krishna Garlapati <krishna@synplicity.com>

I agree with you that $strcat can does both concatenation and conversion and
can be split into 2 functions. We can start with $itos and $itoa and extend
the functionality to include $itosb, $itosh, itoso and anything else
to make it fully specified.

But I still do think that Verilog should provide a function that performs
concatenation and conversion instead of asking the user to write one using
these. This functionality
is too often used, and is much better if Verilog provides a solution natively.

Using the $itos approach, $strcat can be represented as:

(* some_name = $strcat("Hello", "World", $itos(i), $itosb(15) *) //
assume i is 1
resulting in some_name = "HelloWorld14'b1111"

There are a couple of issues here though. Will the proposed $itosb write the
output as 4'b1111 or 1111 or {7{0000}, 1111} ?? You can see that the size of
the output string can vary greatly depending on the approach.
A possible solution is to explicitly specify in the LRM that the size of the
output string of $itos will always be the least possible size size.

Extending these functions to variables is generally a good idea.
The sizing issues that popup can again be addressed pretty easily if the LRM
can impose restrictions on the maximum size of string buffers
that can be generated. (for unknown sizes only at compile time)

I found out that the backend tools are very picky if we any chars are
padded to the output string.
I think we should concatenate the resutant string without any spaces or
delimeters. If the user wants to add leading spaces (or any delimeters)
it can always be done by adding a NULL string within the parameters to $stract.


From: Shalom.Bresticker@motorola.com
To: btf-bugs@boyd.com
Cc:
Subject: enhancement/502: Dynamic Values on attributes
Date: Thu, 13 Nov 2003 12:38:16 +0200 (IST)

With respect to the $itos and similar functions,
I just received the following, showing that others also see need
for such types of functions. Slightly edited.

--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478

---------- Forwarded message ----------
Date: Wed, 12 Nov 2003 14:04:14 -0600
From: Tom Hawkins <tom@launchbird.com>
To: cf-user@launchbird.com
Subject: [cf-user] Repost: Vector Printing

Since cf-announce is going away, I am going to repost a few important
release announcements so they make it into the cf-user archives.

-Tom

---------- Forwarded Message ----------

Subject: [cf-announce] Confluence 0.6.4 -- Vector Printing, MFPUG
Date: Mon, 8 Sep 2003 17:25:56 -0500
From: Tom Hawkins <tom@launchbird.com>
To: cf-announce@launchbird.com
Cc: bhurt@spnz.org

Confluence 0.6.4 located at:
http://www.launchbird.com/cfrl/

---------------
Vector Printing
---------------

A new logic primitive has been introduced with 0.6.4:

{VectorPrint, Enable Message}

VectorPrint prints a vector assumed to be ASCII encoded to standard
output. All language targets support the new primitive, though the
functionality differs slightly between HDL and C/Python. In HDL, the
print statement is embedded in an always/process block and will only
print when the enable is high and either the enable or message has
changed state. In C/Python, the message will print on every
combinatorial calculation, provided enable is true.

Base.cf also includes a few helper functions for vector/string
manipulation:

StringToVector : Converts a string into an ASCII vector constant.
VectorToBin : Converts a vector into an ASCII vector of 1s and 0s.
VectorToHex : Converts a vector into an ASCII vector of hex digits.

Given these functions, it is straight forward to implement the
Display as discussed on the user group. Display variants may be
added to Base.cf in a later release.

Who needs Perl for string manipulation when you've got Confluence
generated Verilog? ;-)

--
Tom Hawkins
Launchbird Design Systems, Inc.
952-200-3790
http://www.launchbird.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: cf-user-unsubscribe@launchbird.com
For additional commands, e-mail: cf-user-help@launchbird.com

Unformatted



Hosted by Boyd Technology