"generate" question
Martin Euredjian
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_...@pacbell.net
where
"0_0_0_0_" = "martineu"
Allan Herriman
<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
Thanks,
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian
To send private email:
0_0_...@pacbell.net
where
"0_0_0_0_" = "martineu"
"Allan Herriman" <allan.herrim...@ctam.com.au.invalid> wrote in
message news:nn12ovghpla2fo2p3...@4ax.com...
Martin Euredjian
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_...@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[i]), .Q15(Q15_OUT[i]), .A3(D[3]), .A2(D[2]), .A1(D[1]),
.A0(D[0]), .CLK(CLK), .D(IN[i]));
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
<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
>
> contain an expression for the value.
>
> 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
> 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)
Allan Herriman
>Allan Herriman <allan.herrim...@ctam.com.au.invalid> wrote in message news:<nn12ovghpla2fo2p3...@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
<allan.herrim...@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
>
> 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?
Martin Euredjian
"Steven Sharp" <sh...@cadence.com> wrote in message
news:3a8e124e.03100...@posting.google.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 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?
Allan Herriman
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.
Steven Sharp
>
> 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
>
> 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
> > (* 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
> 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.
Steven Sharp
>
> 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
>Allan Herriman <allan.herrim...@ctam.com.au.invalid> wrote in message news:<vmh4ovso767q7mvro...@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
> On 7 Oct 2003 15:38:09 -0700, sh...@cadence.com (Steven Sharp) wrote:
>
> >Allan Herriman <allan.herrim...@ctam.com.au.invalid> wrote in message news:<vmh4ovso767q7mvro...@4ax.com>...
>
> >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
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_...@pacbell.net
where
"0_0_0_0_" = "martineu"
"Steven Sharp" <sh...@cadence.com> wrote in message
news:3a8e124e.03100...@posting.google.com...
Steven Sharp
provides you? Assuming that a user-defined attribute is being used
in VHDL, I believe that it must be set to the value of a constant
expression. That constant expression can include values calculated
by a VHDL function that meets certain requirements.
In Verilog, an attribute can be set to the value of a constant
expression. That constant expression can include values calculated
by a Verilog function that meets certain requirements.
As far as I can see, the only difference is that attributes and
constant functions were added to Verilog more recently, so it is
less likely that a tool will have the full capabilities implemented.
In particular, the tool you are using does not provide enough to do
this yet.
Regardless of the language used, it is less convenient for a user
to have to convert numerical values into string form and use that
to set a string-valued attribute, than to use the numerical values
directly to set numeric-valued attributes. Therefore, choosing to
require string-valued attributes for this purpose would be a poor
design decision on the part of the tool implementor.
Allan Herriman
>Can you describe this additional capability that you believe VHDL
>provides you? Assuming that a user-defined attribute is being used
>in VHDL, I believe that it must be set to the value of a constant
>expression. That constant expression can include values calculated
>by a VHDL function that meets certain requirements.
>
>In Verilog, an attribute can be set to the value of a constant
>expression. That constant expression can include values calculated
>by a Verilog function that meets certain requirements.
>
>As far as I can see, the only difference is that attributes and
>constant functions were added to Verilog more recently, so it is
>less likely that a tool will have the full capabilities implemented.
>In particular, the tool you are using does not provide enough to do
>this yet.
There are more differences than that.
Verilog:
- poor string generation capability in constant strings. (This would
be different if $swrite was able to make constant strings. Perhaps
we'll get lucky in the next language rev.)
- no choice of types for attribute values. (Is this correct? I think
you inferred that the value can only be an integer.)
VHDL:
- any function (without restriction) can be used to form attribute
value. This includes some (poor) built-in string manipulation
facilities, so most users roll their own in functions or arrays.
- Supports more types (although these all end up as strings in the
EDIF).
>Regardless of the language used, it is less convenient for a user
>to have to convert numerical values into string form and use that
>to set a string-valued attribute, than to use the numerical values
>directly to set numeric-valued attributes. Therefore, choosing to
>require string-valued attributes for this purpose would be a poor
>design decision on the part of the tool implementor.
The Xilinx tools have been using string based attributes since the
1980s. They've only been using EDIF since the mid-90s though (XNF was
used prior to that). This isn't something that is going to change, so
your arguments about "convenience" are misplaced, and (IMO) show a
lack of appreciation of the FPGA market.
(Sure, if this was being done from scratch, they'd probably use a pair
of integer attributes for placement, but that isn't the case here.)
Here's an example of some VHDL code I wrote in my last job. It shows
both styles of RLOC coords (RC and XY).
(Note that
'&' is the VHDL concatenation operator,
itoa() is a user defined function that converts a (signed) integer to
a string (it's a wrapper around integer'image),
g_fpga_family, h_placement_vernier, etc. are constants or generics
(parameters).)
...
pure function make_rloc (index : integer) return string is
begin
case g_fpga_family is
when FPGA_FAMILY_VIRTEX_2 =>
return "X" & itoa(h_placement_vernier) &
"Y" & itoa((index + v_placement_vernier) / 2);
when FPGA_FAMILY_VIRTEX_E =>
return "R" & itoa((width - index - v_placement_vernier) / 2) &
"C" & itoa(h_placement_vernier / 2) &
".S" & itoa(1 - (h_placement_vernier mod 2));
when others =>
assert FALSE
report "Unsupported FPGA family"
severity failure;
return "FPGA_FAMILY_UNDEFINED";
end case;
end make_rloc;
...
-- This line would normally be in a package somewhere
attribute rloc : string;
...
struct_adder : for i in local_sum'range generate
attribute rloc of u3 : label is make_rloc(i);
begin
...
u3 : xorcy
port map (
o => combinatorial_sum(i),
ci => carry_chain(i),
li => lut_output(i)
);
...
end generate struct_adder;
...
I'd be very interested in knowing if it is possible to translate this
to Verilog, since my current understand is that this isn't possible,
or is at least rather difficult.
(Or if it is possible, the tools won't support it. ;)
Regards,
Allan.
Allan Herriman
<allan.herrim...@ctam.com.au.invalid> wrote:
>- any function (without restriction) can be used to form attribute
>value.
Not quite. It must be a pure function. All values referenced within
the function must be known at elaboration time (i.e. static).
Regards,
Allan.
Martin Euredjian
I think you just don't understand the subject. I don't have the time to
educate you. Oh, I know full-well that you are a Verilog standards expert.
I'm just not sure that you live in the real world. Had you attempted to be
semi-nice instead of condescending I might be inclined to make an effort.
But that would be a total waste of time.
One thing's for sure. You didn't make Cadence look good in my eyes. As a
small business owner I can't tell you that it won't affect my decisions when
it comes to considering Cadence products.
Plonk.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian
To send private email:
0_0_...@pacbell.net
where
"0_0_0_0_" = "martineu"
"Steven Sharp" <sh...@cadence.com> wrote in message
news:3a8e124e.03100...@posting.google.com...