"generate" question

[Martin Euredjian]

In using "generate" with a counter variable to instantiate a number of
SRLC16's (VirtexII) I thought I'd include RLOC's in the code as well. The
problem is that I'm not sure how to have the attribute string created within
the "generate" statement block. It would need to produce something like
this:

//synthesis attribute RLOCK of BIT[0].SRL is X0Y0
//synthesis attribute RLOCK of BIT[1].SRL is X0Y1
//synthesis attribute RLOCK of BIT[2].SRL is X0Y2
//synthesis attribute RLOCK of BIT[3].SRL is X0Y3
//synthesis attribute RLOCK of BIT[4].SRL is X0Y4
....
etc.

Can someone give me a shove in the right direction?

Thanks,


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[Allan Herriman]

On Mon, 06 Oct 2003 06:04:02 GMT, "Martin Euredjian"
<0_0_0_0_@pacbell.net> wrote:

In using "generate" with a counter variable to instantiate a number of
SRLC16's (VirtexII) I thought I'd include RLOC's in the code as well. The
problem is that I'm not sure how to have the attribute string created within
the "generate" statement block. It would need to produce something like
this:

//synthesis attribute RLOCK of BIT[0].SRL is X0Y0
//synthesis attribute RLOCK of BIT[1].SRL is X0Y1
//synthesis attribute RLOCK of BIT[2].SRL is X0Y2
//synthesis attribute RLOCK of BIT[3].SRL is X0Y3
//synthesis attribute RLOCK of BIT[4].SRL is X0Y4
...
etc.

Can someone give me a shove in the right direction?

This is simple to do in VHDL, since the attribute statement can
contain an expression for the value.
E.g.

blah : for i in 0 to 4 generate
attribute RLOC of foo : label is my_function(i)
begin
foo : bar port map ( ... )
end generate;

Verilog still doesn't support attributes in this way. The most recent
revision of the language added a new comment syntax "(*" for
describing attributes, but AFAIK the functionality is still inadequate
for this sort of work.
(If it is adequate, could someone please let me know? I need to use
RLOCs all the time in my code.)

All the major FPGA synthesizers (including the current version of XST
(6.1)) support mixing VHDL and Verilog in the hierarchy, so you can
limit the use of VHDL to just the modules that require attributes.

Other options are:
1. Use a script (e.g. a perl script) to generate the Verilog code and
avoid the use of the generate statement altogether.

2. Use a script (e.g. a perl script) to generate the RLOCs or LOCs in
the UCF, which avoids the need to use attributes in your Verilog
source code. This is ugly, since the UCF is flat (i.e. it contains no
hierarchy). The only upside is that scripting languages tend to be
better at manipulating text strings than HDLs.

BTW, RLOC is the correct spelling (not RLOCK). The back end tools
will silently ignore an attribute called RLOCK.

Regards,
Allan.

 

[Martin Euredjian]

I might consider the mixed VHDL/Verilog option. What a pain...

Thanks,

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"




"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:nn12ovghpla2fo2p3a84m53k437tc6rimt@4ax.com...

On Mon, 06 Oct 2003 06:04:02 GMT, "Martin Euredjian"
0_0_0_0_@pacbell.net> wrote:

In using "generate" with a counter variable to instantiate a number of
SRLC16's (VirtexII) I thought I'd include RLOC's in the code as well.
The
problem is that I'm not sure how to have the attribute string created
within
the "generate" statement block. It would need to produce something like
this:

//synthesis attribute RLOCK of BIT[0].SRL is X0Y0
//synthesis attribute RLOCK of BIT[1].SRL is X0Y1
//synthesis attribute RLOCK of BIT[2].SRL is X0Y2
//synthesis attribute RLOCK of BIT[3].SRL is X0Y3
//synthesis attribute RLOCK of BIT[4].SRL is X0Y4
...
etc.

Can someone give me a shove in the right direction?

This is simple to do in VHDL, since the attribute statement can
contain an expression for the value.
E.g.

blah : for i in 0 to 4 generate
attribute RLOC of foo : label is my_function(i)
begin
foo : bar port map ( ... )
end generate;

Verilog still doesn't support attributes in this way. The most recent
revision of the language added a new comment syntax "(*" for
describing attributes, but AFAIK the functionality is still inadequate
for this sort of work.
(If it is adequate, could someone please let me know? I need to use
RLOCs all the time in my code.)

All the major FPGA synthesizers (including the current version of XST
(6.1)) support mixing VHDL and Verilog in the hierarchy, so you can
limit the use of VHDL to just the modules that require attributes.

Other options are:
1. Use a script (e.g. a perl script) to generate the Verilog code and
avoid the use of the generate statement altogether.

2. Use a script (e.g. a perl script) to generate the RLOCs or LOCs in
the UCF, which avoids the need to use attributes in your Verilog
source code. This is ugly, since the UCF is flat (i.e. it contains no
hierarchy). The only upside is that scripting languages tend to be
better at manipulating text strings than HDLs.

BTW, RLOC is the correct spelling (not RLOCK). The back end tools
will silently ignore an attribute called RLOCK.

Regards,
Allan.

 

[Martin Euredjian]

I just did something that worked, but it's ugly and only applies to this
particular solution. I manually created more RLOC's than I'll need. XST
ignores any RLOC's that are not being used. In the example below this would
be good for up to 16 bits of width.

Like I said, ugly, but it works for this particular module.

Code below (all comments welcome).

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"



module SRL_DLY
#(parameter WIDTH = 8, DELAY = 2)
(
input wire CLK,
input wire [WIDTH - 1:0] IN,
output reg [WIDTH - 1:0] Q_OUT,
output wire [WIDTH - 1:0] Q15_OUT
);

localparam D = DELAY - 2;
wire [WIDTH - 1:0] qw;
genvar i;

generate
for(i=0; i < WIDTH; i=i+1) begin:BIT
SRLC16 SRL(.Q(qw), .Q15(Q15_OUT), .A3(D[3]), .A2(D[2]), .A1(D[1]),
..A0(D[0]), .CLK(CLK), .D(IN));
end
endgenerate

//synthesis attribute RLOC of BIT[0].SRL is X0Y0
//synthesis attribute RLOC of BIT[1].SRL is X0Y1
//synthesis attribute RLOC of BIT[2].SRL is X1Y0
//synthesis attribute RLOC of BIT[3].SRL is X1Y1
//synthesis attribute RLOC of BIT[4].SRL is X0Y2
//synthesis attribute RLOC of BIT[5].SRL is X0Y3
//synthesis attribute RLOC of BIT[6].SRL is X1Y2
//synthesis attribute RLOC of BIT[7].SRL is X1Y3
//synthesis attribute RLOC of BIT[8].SRL is X0Y4
//synthesis attribute RLOC of BIT[9].SRL is X0Y5
//synthesis attribute RLOC of BIT[10].SRL is X1Y4
//synthesis attribute RLOC of BIT[11].SRL is X1Y5
//synthesis attribute RLOC of BIT[12].SRL is X0Y6
//synthesis attribute RLOC of BIT[13].SRL is X0Y7
//synthesis attribute RLOC of BIT[14].SRL is X1Y6
//synthesis attribute RLOC of BIT[15].SRL is X1Y7


// Register the output
always @(posedge CLK) Q_OUT <= qw;


endmodule

 

[Allan Herriman]

On Mon, 06 Oct 2003 07:26:10 GMT, "Martin Euredjian"
<0_0_0_0_@pacbell.net> wrote:

I just did something that worked, but it's ugly and only applies to this
particular solution. I manually created more RLOC's than I'll need. XST
ignores any RLOC's that are not being used. In the example below this would
be good for up to 16 bits of width.

Like I said, ugly, but it works for this particular module.

Code below (all comments welcome).

Clever.

Allan.

 

[Steven Sharp]

Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<nn12ovghpla2fo2p3a84m53k437tc6rimt@4ax.com>...

This is simple to do in VHDL, since the attribute statement can
contain an expression for the value.

Verilog still doesn't support attributes in this way. The most recent
revision of the language added a new comment syntax "(*" for
describing attributes, but AFAIK the functionality is still inadequate
for this sort of work.
(If it is adequate, could someone please let me know? I need to use
RLOCs all the time in my code.)

What is in the 1364-2001 standard is adequate for this.

Note that the old comment syntax is not part of the language, just a kludge
used by certain tools. The language just regards them as comments, which can
contain arbitrary text. The new attribute syntax is part of the language
and can only contain attributes, not arbitrary text. They are comment-like
only in the sense that they aren't supposed to affect the Verilog behavior
(i.e. the simulation behavior).

The Verilog-2001 attribute values can be set with constant expressions,
which allows what you are talking about. I pushed for this because it
allows setting attributes based on parameters, which can be propagated
down through the design hierarchy. It would also allow a genvar to be
used, since they are effectively constant parameters local to an iteration.

This doesn't necessarily mean that you will be able to use them. This
would depend on your tool supporting Verilog-2001 attributes for these
RLOC things. Even if it does, it might just support a subset that only
allows constant literals.

 

[Martin Euredjian]

"Steven Sharp" <sharp@cadence.com> wrote:

The Verilog-2001 attribute values can be set with constant expressions,
which allows what you are talking about. I pushed for this because it
allows setting attributes based on parameters, which can be propagated
down through the design hierarchy. It would also allow a genvar to be
used, since they are effectively constant parameters local to an
iteration.

Well, no luck on this end 'cause it looks like XST does not yet offer
support for the (* ... *) attribute syntax.

So, if the new attribute form only supports constant expressions, how do I
generate RLOC constraints that might require calculation of the X and Y grid
coordinates? (see my prior post for a code example)


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[Allan Herriman]

On 6 Oct 2003 14:23:31 -0700, sharp@cadence.com (Steven Sharp) wrote:

Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<nn12ovghpla2fo2p3a84m53k437tc6rimt@4ax.com>...

Verilog still doesn't support attributes in this way. The most recent
revision of the language added a new comment syntax "(*" for
describing attributes, but AFAIK the functionality is still inadequate
for this sort of work.
(If it is adequate, could someone please let me know? I need to use
RLOCs all the time in my code.)

What is in the 1364-2001 standard is adequate for this.

Note that the old comment syntax is not part of the language, just a kludge
used by certain tools. The language just regards them as comments, which can
contain arbitrary text. The new attribute syntax is part of the language
and can only contain attributes, not arbitrary text. They are comment-like
only in the sense that they aren't supposed to affect the Verilog behavior
(i.e. the simulation behavior).

The Verilog-2001 attribute values can be set with constant expressions,
which allows what you are talking about. I pushed for this because it
allows setting attributes based on parameters, which can be propagated
down through the design hierarchy. It would also allow a genvar to be
used, since they are effectively constant parameters local to an iteration.

Thanks! This is what I was looking for.

I assume it is meant to work this way:

genvar i;
generate
for (i = 0; i <= 4; i=i+1)
begin
(* RLOC = my_function(i) *)
bar foo ( ... );
end
end generate

This doesn't necessarily mean that you will be able to use them. This
would depend on your tool supporting Verilog-2001 attributes for these
RLOC things. Even if it does, it might just support a subset that only
allows constant literals.

XST doesn't flag an error. However, it doesn't seem to do anything
with the attribute

Regards,
Allan.

 

[Allan Herriman]

On Tue, 07 Oct 2003 11:11:16 +1000, Allan Herriman
<allan.herriman.hates.spam@ctam.com.au.invalid> wrote:

[snippage]

This doesn't necessarily mean that you will be able to use them. This
would depend on your tool supporting Verilog-2001 attributes for these
RLOC things. Even if it does, it might just support a subset that only
allows constant literals.

XST doesn't flag an error. However, it doesn't seem to do anything
with the attribute
[that was for XST 5.x]

Also, this page
http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/xst/xst0087_10.html
indicates that XST 6.1 only supports constant literals -
"The attribute_value must be between quotes,"
which means it's fairly useless for the OP's RLOC problem.

Regards,
Allan.

 

[Steven Sharp]

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:<VElgb.12142$Ou6.10801@newssvr25.news.prodigy.com>...

So, if the new attribute form only supports constant expressions, how do I
generate RLOC constraints that might require calculation of the X and Y grid
coordinates? (see my prior post for a code example)

I'm afraid I don't understand your issue. In what case would you need to
calculate grid coordinates that are not constant? And since your synthesis
tool doesn't perform simulation, how would it calculate anything that is
not constant?

 

[Allan Herriman]

On 6 Oct 2003 19:00:27 -0700, sharp@cadence.com (Steven Sharp) wrote:

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:<VElgb.12142$Ou6.10801@newssvr25.news.prodigy.com>...

So, if the new attribute form only supports constant expressions, how do I
generate RLOC constraints that might require calculation of the X and Y grid
coordinates? (see my prior post for a code example)

I'm afraid I don't understand your issue. In what case would you need to
calculate grid coordinates that are not constant? And since your synthesis
tool doesn't perform simulation, how would it calculate anything that is
not constant?

Steve, I think Martin is confusing "constant expressions" (which can
be functions of the loop iterator) with "literal constants".

The constant expressions are adequate for calculating grid
coordinates.
BTW, the next time the language is revised, would you consider beefing
up the string processing capabilities?
Something like a $write or $display that puts its output as a string
instead of going to the screen would be nice.

E.g.

genvar i;
generate
for (i = 0; i <= 4; i=i+1)
begin
(* RLOC = $sprintf("X0Y%d", i) *)
bar foo ( ... );
end
end generate

[ I may be showing my ignorance here; I expect that something
equivalent already exists. ]

Regards,
Allan.

 

[Martin Euredjian]

"Steven Sharp" <sharp@cadence.com> wrote in message
news:3a8e124e.0310061800.1d81ad15@posting.google.com...

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:<VElgb.12142$Ou6.10801@newssvr25.news.prodigy.com>...

So, if the new attribute form only supports constant expressions, how do
I
generate RLOC constraints that might require calculation of the X and Y
grid
coordinates? (see my prior post for a code example)

I'm afraid I don't understand your issue. In what case would you need to
calculate grid coordinates that are not constant? And since your
synthesis
tool doesn't perform simulation, how would it calculate anything that is
not constant?

Let's simplify it. Let's say that a module has a parameter that determines
how many flip-flops are instantiated inside a "generate" construct. Each of
those flip-flops requires an RLOC attribute of the form:

(* RLOC = XnYm *)

Where, "n" and "m" are integers.

To make it even simpler, let's fix "n" at 0. So:

(* RLOC = X0Ym *)

Then, for our hypothetical module, "m" would go from 0 to the number of
flip-flops called for by the parameter. If the parameter is equal to four:

(* RLOC = X0Y0 *)
(* RLOC = X0Y1 *)
(* RLOC = X0Y2 *)
(* RLOC = X0Y3 *)

If it is equal to six:
(* RLOC = X0Y0 *)
(* RLOC = X0Y1 *)
(* RLOC = X0Y2 *)
(* RLOC = X0Y3 *)
(* RLOC = X0Y4 *)
(* RLOC = X0Y5 *)

How do I make this happen with the new syntax inside a "generate" block?


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[Steven Sharp]

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:<9etgb.12267$v75.8880@newssvr25.news.prodigy.com>...

Let's simplify it. Let's say that a module has a parameter that determines
how many flip-flops are instantiated inside a "generate" construct. Each of
those flip-flops requires an RLOC attribute of the form:

(* RLOC = XnYm *)

Where, "n" and "m" are integers.

To start with, a value like X0Y0 is not a valid Verilog value. It is an
identifier, and (assuming you haven't declared a parameter with this name)
you should get an undeclared identifier error. You can't assign it to an
attribute any more than you could assign it to a reg. This is not a comment,
where they can use any syntax they like. It is Verilog, and they have to use
legal Verilog syntax for a value.

There are a couple of ways that they could set up the RLOC attribute to work.
One would be to have you provide a string value, such as "X0Y0". This would
be the most similar to what they have now, but it would be clumsy to use the
way you want. You might be able to build the string you need from numerical
values, but it would be very ugly. So for the non-generate case, it would
be the simple:

(* RLOC = "X0Y0" *)

but it would not be practical to do what you want. A better way for them
to define it would be to support separate RLOC_X and RLOC_Y attributes,
which would be set to numerical values. Then the simple case would be

(* RLOC_X = 0, RLOC_Y = 0 *)

And the generated case, for two nested loops with genvars i and j:

(* RLOC_X = i, RLOC_Y = j *)

Unfortunately, they will probably pick the inflexible string approach.

How do I make this happen with the new syntax inside a "generate" block?

Let your vendor know what you need to do, and pass along this description
of how they can support it. It is really up to them and what their tool
accepts. They can make this easy, or not.

 

[Steven Sharp]

Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<vmh4ovso767q7mvro63b3dqp680hl40gj2@4ax.com>...

BTW, the next time the language is revised, would you consider beefing
up the string processing capabilities?
Something like a $write or $display that puts its output as a string
instead of going to the screen would be nice.

Verilog-2001 added $swrite tasks that write their output string into
a variable instead of to a file. It also added a new $sformat task that
allows a variable to be used as a format string when writing a string
into another variable.

This isn't useful for your attribute example, however. They are tasks
rather than functions, and even system functions can't be used in constant
expressions (though I have proposed that this be allowed for a few of the
system functions that are pure functions, basically the type conversion
functions). The proper solution to your attribute situation is for the
tools to stop having you provide the values packed into a string, and
instead have you provide them as integer values.

 

[Martin Euredjian]

"Steven Sharp" wrote:

(* RLOC = XnYm *)

Where, "n" and "m" are integers.

To start with, a value like X0Y0 is not a valid Verilog value. It is an
identifier, and (assuming you haven't declared a parameter with this name)
you should get an undeclared identifier error. You can't assign it to an
attribute any more than you could assign it to a reg. This is not a
comment,
where they can use any syntax they like. It is Verilog, and they have to
use
legal Verilog syntax for a value.

I guess I have to apologize for being imprecise. Yes, I meant to use a
string ... "XnYm" or maybe a variable that contained a string. Not knowing
what other resources might be available in the language I simply made the
assumption that a variable would be used and that I'd build the string
somewhere. This would allow as complex an algorithm as required to build
the string in question without having to clutter the attribute statement.

Thanks for the scolding.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[Martin Euredjian]

"Steven Sharp" wrote:

The proper solution to your attribute situation is for the
tools to stop having you provide the values packed into a string, and
instead have you provide them as integer values.

This bothers me a bit. Why is this more "proper" than using a string? This
makes no sense to me. There's nothing wrong with programatically building
string, regardless of where/how they are to be used. It would be much
simpler to enhance the language with the required capability than want to
force a change like that. Besides, you can do this with VHDL. This sort of
inflexibility may just be the proverbial straw on the camel's back that
finally pushes me to switch to VHDL.


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[Steven Sharp]

Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<ld34ovo3hprgnindqg2ni979n0d2gb2m68@4ax.com>...

I assume it is meant to work this way:

genvar i;
generate
for (i = 0; i <= 4; i=i+1)
begin
(* RLOC = my_function(i) *)
bar foo ( ... );
end
end generate

Yes, that is how you would do it. Note that if you actually used a Verilog
function for the computation (rather than my_function(i) just being a notation
for an arbitrary expression involving i), then you would be relying on yet
another extension: constant functions.

XST doesn't flag an error. However, it doesn't seem to do anything
with the attribute

The feature is there to be used for this kind of thing, but it is up to
them to do something with it. Maybe if enough users ask for it...

 

[Allan Herriman]

On 7 Oct 2003 15:38:09 -0700, sharp@cadence.com (Steven Sharp) wrote:

Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<vmh4ovso767q7mvro63b3dqp680hl40gj2@4ax.com>...

BTW, the next time the language is revised, would you consider beefing
up the string processing capabilities?
Something like a $write or $display that puts its output as a string
instead of going to the screen would be nice.

Verilog-2001 added $swrite tasks that write their output string into
a variable instead of to a file. It also added a new $sformat task that
allows a variable to be used as a format string when writing a string
into another variable.

Ha! Good ...

This isn't useful for your attribute example, however. They are tasks
rather than functions, and even system functions can't be used in constant
expressions (though I have proposed that this be allowed for a few of the
system functions that are pure functions, basically the type conversion
functions).

Was this because the tool vendors didn't want to have to do too much
work, or because of some fundamental problem?

The proper solution to your attribute situation is for the
tools to stop having you provide the values packed into a string, and
instead have you provide them as integer values.

That is "proper" from whose perspective?

Allan.

 

[Steven Sharp]

Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<umo6ovoq5ijf0agsleeosq822hnqn644pi@4ax.com>...

On 7 Oct 2003 15:38:09 -0700, sharp@cadence.com (Steven Sharp) wrote:

Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<vmh4ovso767q7mvro63b3dqp680hl40gj2@4ax.com>...

The proper solution to your attribute situation is for the
tools to stop having you provide the values packed into a string, and
instead have you provide them as integer values.

That is "proper" from whose perspective?

Both the tool implementor and the tool user.

I see the following possible design choices for the tool implementor:

1. The tool implementor supports two numerical-valued attributes for the
X and Y coordinates, and allows constant expressions for them. The user
can easily use expressions of numerical-valued constants such as genvars
or parameters, or simple numeric literals, to set them.

2. The tool implementor supports a string-valued attribute that contains
the X and Y coordinates. To allow the user to conveniently set the
attribute value from numerical-valued constants, the tool implementor
supports a complex set of extensions which would take a lot of work to
implement, would be inconsistent with all other similar constructs in
the language (e.g. how parameters are set), and would be non-standard.
The user would have to figure out how to use these mechanisms to create
a string from the numeric values, which takes the user a lot more work
and is more difficult for anyone to read and understand. And since they
might make a mistake in creating the string (e.g. using the wrong format,
leaving spaces that the tool might not accept), they need debugging
facilities to at least dump the value that they ended up generating.
And the only apparent use for this facility is to work around the tool
implementor's decision to require a string-valued attribute (which they
will then have to parse to convert back to numerical values).

3. The tool implementor supports a string-valued attribute that contains
the X and Y coordinates as characters. The tool implementor provides
the standard support for constant expressions, including constant
functions. The user can still set the attribute values using standard
mechanisms such as constant functions to program the computation of the
values. But now the user is responsible for providing their own version
of the string formatting functions they need, written in Verilog. They
probably need even more complex debug facilities, since they are writing
more complex code themselves. The tool implementor could help out by
providing the source for a suitable Verilog function that takes the two
numerical values and produces a string. Then the user would just have to
include that Verilog function and call it, which is still more complex
and difficult to understand than using the numerical values directly.

4. The tool implementor supports only string literals as attributes and
provides the user no way of computing the coordinates.

I suspect that what you are getting in this case is number 4. Perhaps the
tool implementor considers that to be the "proper" way to do it, since it
doesn't require any work from them. But you as a user probably don't, and
if the tool implementor cares about users, they shouldn't either.

Of the remaining choices, 1 is clearly superior in all respects. It is
easiest for the tool implementor to do, and easiest for the user to use.
If the tool implementor wants to provide this capability, it is the best
design choice. In my opinion, that makes it the proper way to do it.

 

[Martin Euredjian]

All well and fine, but, it seems to me, that the standards body made a one
sided decision to not allow the sort of string manipulation and assignment
that would be VERY useful to have today, not in five years, today. Let me
decide if I want to go through the drudgery of writing string manipulation
functions.

Like I said in a prior post. VHDL can do this now. I was wrong, VHDL has
been able to do this for years, I think as far back as '87!!?? In my world
I care about designing and manufacturing widgets. Getting these widgets out
to market quickly requires powerful and flexible tools. I'm not a Verilog
fanatic. It's just one tool in the arsenal. I don't know VHDL at all, and
it will be painful and costly to migrate, but it sure seems like that camp
cares a lot more about being flexible than this camp.

So, if Verilog is getting in the way of getting things done, it's out the
window. These language implementation choices may be source for great
philosophical discussions. But, from the trenches, what's really important
is having enough flexibility to at least compete with what the other guys
can do. Here I am stuck with inferior language facilities 'cause someone
thought that the other way is not "proper". Great.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"




"Steven Sharp" <sharp@cadence.com> wrote in message
news:3a8e124e.0310081708.6fdd961e@posting.google.com...

Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:<umo6ovoq5ijf0agsleeosq822hnqn644pi@4ax.com>...
On 7 Oct 2003 15:38:09 -0700, sharp@cadence.com (Steven Sharp) wrote:

Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:<vmh4ovso767q7mvro63b3dqp680hl40gj2@4ax.com>...

The proper solution to your attribute situation is for the
tools to stop having you provide the values packed into a string, and
instead have you provide them as integer values.

That is "proper" from whose perspective?

Both the tool implementor and the tool user.

I see the following possible design choices for the tool implementor:

1. The tool implementor supports two numerical-valued attributes for the
X and Y coordinates, and allows constant expressions for them. The
user
can easily use expressions of numerical-valued constants such as
genvars
or parameters, or simple numeric literals, to set them.

2. The tool implementor supports a string-valued attribute that contains
the X and Y coordinates. To allow the user to conveniently set the
attribute value from numerical-valued constants, the tool implementor
supports a complex set of extensions which would take a lot of work to
implement, would be inconsistent with all other similar constructs in
the language (e.g. how parameters are set), and would be non-standard.
The user would have to figure out how to use these mechanisms to create
a string from the numeric values, which takes the user a lot more work
and is more difficult for anyone to read and understand. And since
they
might make a mistake in creating the string (e.g. using the wrong
format,
leaving spaces that the tool might not accept), they need debugging
facilities to at least dump the value that they ended up generating.
And the only apparent use for this facility is to work around the tool
implementor's decision to require a string-valued attribute (which they
will then have to parse to convert back to numerical values).

3. The tool implementor supports a string-valued attribute that contains
the X and Y coordinates as characters. The tool implementor provides
the standard support for constant expressions, including constant
functions. The user can still set the attribute values using standard
mechanisms such as constant functions to program the computation of the
values. But now the user is responsible for providing their own
version
of the string formatting functions they need, written in Verilog. They
probably need even more complex debug facilities, since they are
writing
more complex code themselves. The tool implementor could help out by
providing the source for a suitable Verilog function that takes the two
numerical values and produces a string. Then the user would just have
to
include that Verilog function and call it, which is still more complex
and difficult to understand than using the numerical values directly.

4. The tool implementor supports only string literals as attributes and
provides the user no way of computing the coordinates.

I suspect that what you are getting in this case is number 4. Perhaps the
tool implementor considers that to be the "proper" way to do it, since it
doesn't require any work from them. But you as a user probably don't, and
if the tool implementor cares about users, they shouldn't either.

Of the remaining choices, 1 is clearly superior in all respects. It is
easiest for the tool implementor to do, and easiest for the user to use.
If the tool implementor wants to provide this capability, it is the best
design choice. In my opinion, that makes it the proper way to do it.