Menu
▾
▴
iverilog-devel
|
From: Guy H. <ghu...@gm...> - 2012-03-23 21:50:58
|
Not sure if this is an Icarus question or an LRM question, but while
refactoring some code with generate statements I ran across this error
message:
sd_rrmux.v:151: error: Scope index expression is not constant: j
The code that caused the error was:
generate
for (i=0; i<inputs; i=i+1)
begin : grid_assign
wire [width-1:0] temp;
assign temp = c_data >> (i*width);
//assign rr_mux_grid[i] = c_data >> (i*width);
end
endgenerate
always @*
begin
p_data = 0;
p_srdy = 0;
for (j=0; j<inputs; j=j+1)
if (rr_state[j])
begin
//p_data = rr_mux_grid[j];
p_data = grid_assign[j].temp;
p_srdy = c_srdy[j];
end
end
A synthesis tool has no problem figuring out that j is constant within
the begin-end scope listed here; why is it not "constant" for picking
up a scope reference? This also fails within a generate loop using a
genvar as the index var.
|
|
From: Martin W. <mai...@ma...> - 2012-03-23 22:23:16
|
I think it's a LRM question. From section 12.5 of the standard "Names in a hierarchical path name that refer to instance arrays or loop generate blocks may be followed immediately by a constant expression in square brackets." Constant expressions are defined in annex A (formal syntax) and are defined to be one or more constant primaries (combined by appropriate operators). A constant primary is defined as constant_primary ::= number | parameter_identifier [ [ constant_range_expression ] ] | specparam_identifier [ [ constant_range_expression ] ] | constant_concatenation | constant_multiple_concatenation | constant_function_call | constant_system_function_call | ( constant_mintypmax_expression ) | string 'j' in your code must be a hierarchical identifier (otherwise you couldn't use it as a loop variable), so is not a valid constant primary. So what you have written is not legal Verilog - even if a synthesis tool accepts it. Guy Hutchison wrote: > Not sure if this is an Icarus question or an LRM question, but while > refactoring some code with generate statements I ran across this error > message: > > sd_rrmux.v:151: error: Scope index expression is not constant: j > > The code that caused the error was: > generate > for (i=0; i<inputs; i=i+1) > begin : grid_assign > wire [width-1:0] temp; > assign temp = c_data>> (i*width); > //assign rr_mux_grid[i] = c_data>> (i*width); > end > endgenerate > always @* > begin > p_data = 0; > p_srdy = 0; > for (j=0; j<inputs; j=j+1) > if (rr_state[j]) > begin > //p_data = rr_mux_grid[j]; > p_data = grid_assign[j].temp; > p_srdy = c_srdy[j]; > end > end > > A synthesis tool has no problem figuring out that j is constant within > the begin-end scope listed here; why is it not "constant" for picking > up a scope reference? This also fails within a generate loop using a > genvar as the index var. > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel |
|
From: Guy H. <ghu...@gm...> - 2012-03-23 22:45:35
|
But if I recode it as follows:
genvar g;
wire [width-1:0] insel0;
assign insel0 = (rr_state[0]) ? c_data[width-1:0] : {width{1'b0}};
assign p_srdy = |(rr_state & c_srdy);
generate
for (g=1; g<inputs; g=g+1)
begin : breakout
wire [width-1:0] insel;
assign insel = (rr_state[g]) ? c_data >> (g*width) : breakout[g-1].insel;
end
endgenerate
assign p_data = breakout[inputs-1].insel;
then I get the error:
error: Unable to bind wire/reg/memory `breakout[(g)-('sd1)].insel' in
`env_top.bridge.control0.fib_arb.breakout[1]
At this point everything is clearly constant, although icarus
complains as above and Verilator complains that it can't shift by a
non-constant value (width is a parameter).
BTW, this whole rathole was triggered by Verilator complaining about
the original syntax I have for this being unoptimizable due to a for
loop.
On 3/23/12, Martin Whitaker <mai...@ma...> wrote:
> I think it's a LRM question. From section 12.5 of the standard
>
> "Names in a hierarchical path name that refer to instance arrays or loop
> generate blocks may be followed immediately by a constant expression in
> square
> brackets."
>
> Constant expressions are defined in annex A (formal syntax) and are defined
> to
> be one or more constant primaries (combined by appropriate operators). A
> constant primary is defined as
>
> constant_primary ::=
> number
> | parameter_identifier [ [ constant_range_expression ] ]
> | specparam_identifier [ [ constant_range_expression ] ]
> | constant_concatenation
> | constant_multiple_concatenation
> | constant_function_call
> | constant_system_function_call
> | ( constant_mintypmax_expression )
> | string
>
> 'j' in your code must be a hierarchical identifier (otherwise you couldn't
> use
> it as a loop variable), so is not a valid constant primary.
>
> So what you have written is not legal Verilog - even if a synthesis tool
> accepts it.
>
>
> Guy Hutchison wrote:
>> Not sure if this is an Icarus question or an LRM question, but while
>> refactoring some code with generate statements I ran across this error
>> message:
>>
>> sd_rrmux.v:151: error: Scope index expression is not constant: j
>>
>> The code that caused the error was:
>> generate
>> for (i=0; i<inputs; i=i+1)
>> begin : grid_assign
>> wire [width-1:0] temp;
>> assign temp = c_data>> (i*width);
>> //assign rr_mux_grid[i] = c_data>> (i*width);
>> end
>> endgenerate
>> always @*
>> begin
>> p_data = 0;
>> p_srdy = 0;
>> for (j=0; j<inputs; j=j+1)
>> if (rr_state[j])
>> begin
>> //p_data = rr_mux_grid[j];
>> p_data = grid_assign[j].temp;
>> p_srdy = c_srdy[j];
>> end
>> end
>>
>> A synthesis tool has no problem figuring out that j is constant within
>> the begin-end scope listed here; why is it not "constant" for picking
>> up a scope reference? This also fails within a generate loop using a
>> genvar as the index var.
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
|
|
From: Iztok J. <izt...@gm...> - 2012-03-23 22:58:49
|
Hi guy,
It seems you are addressing "breakout[g-1].insel" if g==1 then you are
looking for "breakout[0].insel" which does not exist, since g={1, 2,
... inputs-1} there is no loop element for breakout[0].
Also it seems to me king of strange you are addressing an object
horizontally in the hierarchy, I am not used to such use, I usually
see vertical access to smaller hierarchies. I do not even know if this
is legal. If it is please reassure me.
Regards,
Iztok Jeras
On Fri, Mar 23, 2012 at 23:45, Guy Hutchison <ghu...@gm...> wrote:
> But if I recode it as follows:
>
> genvar g;
>
> wire [width-1:0] insel0;
> assign insel0 = (rr_state[0]) ? c_data[width-1:0] : {width{1'b0}};
> assign p_srdy = |(rr_state & c_srdy);
>
> generate
> for (g=1; g<inputs; g=g+1)
> begin : breakout
> wire [width-1:0] insel;
> assign insel = (rr_state[g]) ? c_data >> (g*width) : breakout[g-1].insel;
> end
> endgenerate
> assign p_data = breakout[inputs-1].insel;
>
> then I get the error:
> error: Unable to bind wire/reg/memory `breakout[(g)-('sd1)].insel' in
> `env_top.bridge.control0.fib_arb.breakout[1]
>
> At this point everything is clearly constant, although icarus
> complains as above and Verilator complains that it can't shift by a
> non-constant value (width is a parameter).
>
> BTW, this whole rathole was triggered by Verilator complaining about
> the original syntax I have for this being unoptimizable due to a for
> loop.
>
> On 3/23/12, Martin Whitaker <mai...@ma...> wrote:
>> I think it's a LRM question. From section 12.5 of the standard
>>
>> "Names in a hierarchical path name that refer to instance arrays or loop
>> generate blocks may be followed immediately by a constant expression in
>> square
>> brackets."
>>
>> Constant expressions are defined in annex A (formal syntax) and are defined
>> to
>> be one or more constant primaries (combined by appropriate operators). A
>> constant primary is defined as
>>
>> constant_primary ::=
>> number
>> | parameter_identifier [ [ constant_range_expression ] ]
>> | specparam_identifier [ [ constant_range_expression ] ]
>> | constant_concatenation
>> | constant_multiple_concatenation
>> | constant_function_call
>> | constant_system_function_call
>> | ( constant_mintypmax_expression )
>> | string
>>
>> 'j' in your code must be a hierarchical identifier (otherwise you couldn't
>> use
>> it as a loop variable), so is not a valid constant primary.
>>
>> So what you have written is not legal Verilog - even if a synthesis tool
>> accepts it.
>>
>>
>> Guy Hutchison wrote:
>>> Not sure if this is an Icarus question or an LRM question, but while
>>> refactoring some code with generate statements I ran across this error
>>> message:
>>>
>>> sd_rrmux.v:151: error: Scope index expression is not constant: j
>>>
>>> The code that caused the error was:
>>> generate
>>> for (i=0; i<inputs; i=i+1)
>>> begin : grid_assign
>>> wire [width-1:0] temp;
>>> assign temp = c_data>> (i*width);
>>> //assign rr_mux_grid[i] = c_data>> (i*width);
>>> end
>>> endgenerate
>>> always @*
>>> begin
>>> p_data = 0;
>>> p_srdy = 0;
>>> for (j=0; j<inputs; j=j+1)
>>> if (rr_state[j])
>>> begin
>>> //p_data = rr_mux_grid[j];
>>> p_data = grid_assign[j].temp;
>>> p_srdy = c_srdy[j];
>>> end
>>> end
>>>
>>> A synthesis tool has no problem figuring out that j is constant within
>>> the begin-end scope listed here; why is it not "constant" for picking
>>> up a scope reference? This also fails within a generate loop using a
>>> genvar as the index var.
>>>
>>> ------------------------------------------------------------------------------
>>> This SF email is sponsosred by:
>>> Try Windows Azure free for 90 days Click Here
>>> http://p.sf.net/sfu/sfd2d-msazure
>>> _______________________________________________
>>> Iverilog-devel mailing list
>>> Ive...@li...
>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
|
From: Cary R. <cy...@ya...> - 2012-03-23 23:01:38
|
Guy,
Where is the breakout[0] scope defined? That's what is being accessed the first time. Do you need a conditional to connect the first iteration to something else? I may have missed something in my quick look, but this code looks wrong. I believe the previous code was incorrect because an implicit generate for cannot be inside procedural code.
Cary
----- Original Message -----
From: Guy Hutchison <ghu...@gm...>
To: Discussions concerning Icarus Verilog development <ive...@li...>
Cc:
Sent: Friday, March 23, 2012 3:45 PM
Subject: Re: [Iverilog-devel] What is a constant?
But if I recode it as follows:
genvar g;
wire [width-1:0] insel0;
assign insel0 = (rr_state[0]) ? c_data[width-1:0] : {width{1'b0}};
assign p_srdy = |(rr_state & c_srdy);
generate
for (g=1; g<inputs; g=g+1)
begin : breakout
wire [width-1:0] insel;
assign insel = (rr_state[g]) ? c_data >> (g*width) : breakout[g-1].insel;
end
endgenerate
assign p_data = breakout[inputs-1].insel;
then I get the error:
error: Unable to bind wire/reg/memory `breakout[(g)-('sd1)].insel' in
`env_top.bridge.control0.fib_arb.breakout[1]
At this point everything is clearly constant, although icarus
complains as above and Verilator complains that it can't shift by a
non-constant value (width is a parameter).
BTW, this whole rathole was triggered by Verilator complaining about
the original syntax I have for this being unoptimizable due to a for
loop.
On 3/23/12, Martin Whitaker <mai...@ma...> wrote:
> I think it's a LRM question. From section 12.5 of the standard
>
> "Names in a hierarchical path name that refer to instance arrays or loop
> generate blocks may be followed immediately by a constant expression in
> square
> brackets."
>
> Constant expressions are defined in annex A (formal syntax) and are defined
> to
> be one or more constant primaries (combined by appropriate operators). A
> constant primary is defined as
>
> constant_primary ::=
> number
> | parameter_identifier [ [ constant_range_expression ] ]
> | specparam_identifier [ [ constant_range_expression ] ]
> | constant_concatenation
> | constant_multiple_concatenation
> | constant_function_call
> | constant_system_function_call
> | ( constant_mintypmax_expression )
> | string
>
> 'j' in your code must be a hierarchical identifier (otherwise you couldn't
> use
> it as a loop variable), so is not a valid constant primary.
>
> So what you have written is not legal Verilog - even if a synthesis tool
> accepts it.
>
>
> Guy Hutchison wrote:
>> Not sure if this is an Icarus question or an LRM question, but while
>> refactoring some code with generate statements I ran across this error
>> message:
>>
>> sd_rrmux.v:151: error: Scope index expression is not constant: j
>>
>> The code that caused the error was:
>> generate
>> for (i=0; i<inputs; i=i+1)
>> begin : grid_assign
>> wire [width-1:0] temp;
>> assign temp = c_data>> (i*width);
>> //assign rr_mux_grid[i] = c_data>> (i*width);
>> end
>> endgenerate
>> always @*
>> begin
>> p_data = 0;
>> p_srdy = 0;
>> for (j=0; j<inputs; j=j+1)
>> if (rr_state[j])
>> begin
>> //p_data = rr_mux_grid[j];
>> p_data = grid_assign[j].temp;
>> p_srdy = c_srdy[j];
>> end
>> end
>>
>> A synthesis tool has no problem figuring out that j is constant within
>> the begin-end scope listed here; why is it not "constant" for picking
>> up a scope reference? This also fails within a generate loop using a
>> genvar as the index var.
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
|
From: Stephen W. <st...@ic...> - 2012-03-23 23:09:23
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
There is no breakout[0]. When g==1, your generated assign will be:
assign insel = (rr_state[1]) ? c_data >> (1*width) : breakout[0].insel;
but since breakout[0] is not generated, the reference to
(breakout[0].insel) fails.
On 03/23/2012 03:45 PM, Guy Hutchison wrote:
> But if I recode it as follows:
>
> genvar g;
>
> wire [width-1:0] insel0; assign insel0 = (rr_state[0]) ?
> c_data[width-1:0] : {width{1'b0}}; assign p_srdy = |(rr_state &
> c_srdy);
>
> generate for (g=1; g<inputs; g=g+1) begin : breakout wire
> [width-1:0] insel; assign insel = (rr_state[g]) ? c_data >>
> (g*width) : breakout[g-1].insel; end endgenerate assign p_data =
> breakout[inputs-1].insel;
>
> then I get the error: error: Unable to bind wire/reg/memory
> `breakout[(g)-('sd1)].insel' in
> `env_top.bridge.control0.fib_arb.breakout[1]
>
> At this point everything is clearly constant, although icarus
> complains as above and Verilator complains that it can't shift by
> a non-constant value (width is a parameter).
>
> BTW, this whole rathole was triggered by Verilator complaining
> about the original syntax I have for this being unoptimizable due
> to a for loop.
>
> On 3/23/12, Martin Whitaker <mai...@ma...>
> wrote:
>> I think it's a LRM question. From section 12.5 of the standard
>>
>> "Names in a hierarchical path name that refer to instance arrays
>> or loop generate blocks may be followed immediately by a constant
>> expression in square brackets."
>>
>> Constant expressions are defined in annex A (formal syntax) and
>> are defined to be one or more constant primaries (combined by
>> appropriate operators). A constant primary is defined as
>>
>> constant_primary ::= number | parameter_identifier [ [
>> constant_range_expression ] ] | specparam_identifier [ [
>> constant_range_expression ] ] | constant_concatenation |
>> constant_multiple_concatenation | constant_function_call |
>> constant_system_function_call | ( constant_mintypmax_expression
>> ) | string
>>
>> 'j' in your code must be a hierarchical identifier (otherwise you
>> couldn't use it as a loop variable), so is not a valid constant
>> primary.
>>
>> So what you have written is not legal Verilog - even if a
>> synthesis tool accepts it.
>>
>>
>> Guy Hutchison wrote:
>>> Not sure if this is an Icarus question or an LRM question, but
>>> while refactoring some code with generate statements I ran
>>> across this error message:
>>>
>>> sd_rrmux.v:151: error: Scope index expression is not constant:
>>> j
>>>
>>> The code that caused the error was: generate for (i=0;
>>> i<inputs; i=i+1) begin : grid_assign wire [width-1:0] temp;
>>> assign temp = c_data>> (i*width); //assign rr_mux_grid[i] =
>>> c_data>> (i*width); end endgenerate always @* begin p_data =
>>> 0; p_srdy = 0; for (j=0; j<inputs; j=j+1) if (rr_state[j])
>>> begin //p_data = rr_mux_grid[j]; p_data = grid_assign[j].temp;
>>> p_srdy = c_srdy[j]; end end
>>>
>>> A synthesis tool has no problem figuring out that j is constant
>>> within the begin-end scope listed here; why is it not
>>> "constant" for picking up a scope reference? This also fails
>>> within a generate loop using a genvar as the index var.
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
This SF email is sponsosred by:
>>> Try Windows Azure free for 90 days Click Here
>>> http://p.sf.net/sfu/sfd2d-msazure
>>> _______________________________________________
- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9tApgACgkQrPt1Sc2b3ikKKwCfRjlS5duvb7qATrYZeWWn7iOo
bhkAoNl1TyTu7R+WrkFhv2tw95XRX1ey
=EMgA
-----END PGP SIGNATURE-----
|
|
From: Guy H. <ghu...@gm...> - 2012-03-23 23:30:07
|
Good catch by all replies, changing this to:
generate
for (g=0; g<inputs; g=g+1)
begin : breakout
wire [width-1:0] insel;
if (g==0)
assign insel = (rr_state[0]) ? c_data[width-1:0] : {width{1'b0}};
else
assign insel = (rr_state[g]) ? c_data >> (g*width) :
breakout[g-1].insel;
end
endgenerate
assign p_data = breakout[inputs-1].insel;
Fixes the access-zero problem, as zero is the special case.
As to why I am using this goofy structure, it is because building a
parameterized mux is a little painful if you have to have constant bit
selects, so I'm forced in to more odd constructions.
On 3/23/12, Stephen Williams <st...@ic...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> There is no breakout[0]. When g==1, your generated assign will be:
>
> assign insel = (rr_state[1]) ? c_data >> (1*width) : breakout[0].insel;
>
> but since breakout[0] is not generated, the reference to
> (breakout[0].insel) fails.
>
> On 03/23/2012 03:45 PM, Guy Hutchison wrote:
>> But if I recode it as follows:
>>
>> genvar g;
>>
>> wire [width-1:0] insel0; assign insel0 = (rr_state[0]) ?
>> c_data[width-1:0] : {width{1'b0}}; assign p_srdy = |(rr_state &
>> c_srdy);
>>
>> generate for (g=1; g<inputs; g=g+1) begin : breakout wire
>> [width-1:0] insel; assign insel = (rr_state[g]) ? c_data >>
>> (g*width) : breakout[g-1].insel; end endgenerate assign p_data =
>> breakout[inputs-1].insel;
>>
>> then I get the error: error: Unable to bind wire/reg/memory
>> `breakout[(g)-('sd1)].insel' in
>> `env_top.bridge.control0.fib_arb.breakout[1]
>>
>> At this point everything is clearly constant, although icarus
>> complains as above and Verilator complains that it can't shift by
>> a non-constant value (width is a parameter).
>>
>> BTW, this whole rathole was triggered by Verilator complaining
>> about the original syntax I have for this being unoptimizable due
>> to a for loop.
>>
>> On 3/23/12, Martin Whitaker <mai...@ma...>
>> wrote:
>>> I think it's a LRM question. From section 12.5 of the standard
>>>
>>> "Names in a hierarchical path name that refer to instance arrays
>>> or loop generate blocks may be followed immediately by a constant
>>> expression in square brackets."
>>>
>>> Constant expressions are defined in annex A (formal syntax) and
>>> are defined to be one or more constant primaries (combined by
>>> appropriate operators). A constant primary is defined as
>>>
>>> constant_primary ::= number | parameter_identifier [ [
>>> constant_range_expression ] ] | specparam_identifier [ [
>>> constant_range_expression ] ] | constant_concatenation |
>>> constant_multiple_concatenation | constant_function_call |
>>> constant_system_function_call | ( constant_mintypmax_expression
>>> ) | string
>>>
>>> 'j' in your code must be a hierarchical identifier (otherwise you
>>> couldn't use it as a loop variable), so is not a valid constant
>>> primary.
>>>
>>> So what you have written is not legal Verilog - even if a
>>> synthesis tool accepts it.
>>>
>>>
>>> Guy Hutchison wrote:
>>>> Not sure if this is an Icarus question or an LRM question, but
>>>> while refactoring some code with generate statements I ran
>>>> across this error message:
>>>>
>>>> sd_rrmux.v:151: error: Scope index expression is not constant:
>>>> j
>>>>
>>>> The code that caused the error was: generate for (i=0;
>>>> i<inputs; i=i+1) begin : grid_assign wire [width-1:0] temp;
>>>> assign temp = c_data>> (i*width); //assign rr_mux_grid[i] =
>>>> c_data>> (i*width); end endgenerate always @* begin p_data =
>>>> 0; p_srdy = 0; for (j=0; j<inputs; j=j+1) if (rr_state[j])
>>>> begin //p_data = rr_mux_grid[j]; p_data = grid_assign[j].temp;
>>>> p_srdy = c_srdy[j]; end end
>>>>
>>>> A synthesis tool has no problem figuring out that j is constant
>>>> within the begin-end scope listed here; why is it not
>>>> "constant" for picking up a scope reference? This also fails
>>>> within a generate loop using a genvar as the index var.
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
> This SF email is sponsosred by:
>>>> Try Windows Azure free for 90 days Click Here
>>>> http://p.sf.net/sfu/sfd2d-msazure
>>>> _______________________________________________
>
>
> - --
> Steve Williams "The woods are lovely, dark and deep.
> steve at icarus.com But I have promises to keep,
> http://www.icarus.com and lines to code before I sleep,
> http://www.picturel.com And lines to code before I sleep."
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.16 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk9tApgACgkQrPt1Sc2b3ikKKwCfRjlS5duvb7qATrYZeWWn7iOo
> bhkAoNl1TyTu7R+WrkFhv2tw95XRX1ey
> =EMgA
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
|
|
From: Stephen W. <st...@ic...> - 2012-03-23 23:39:33
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
When you are indexing a scope (i.e. a generated block in your case)
the index must be constant. Sorry, them's the rules. I think in your
first example you were not using a generate block at all but a
behavioral for-loop that your synthesizer was able to unroll. It
seems that Verilator is not as clever as your synthesizer.
On 03/23/2012 04:29 PM, Guy Hutchison wrote:
> Good catch by all replies, changing this to: generate for (g=0;
> g<inputs; g=g+1) begin : breakout wire [width-1:0] insel; if
> (g==0) assign insel = (rr_state[0]) ? c_data[width-1:0] :
> {width{1'b0}}; else assign insel = (rr_state[g]) ? c_data >>
> (g*width) : breakout[g-1].insel; end endgenerate assign p_data =
> breakout[inputs-1].insel;
>
> Fixes the access-zero problem, as zero is the special case.
>
> As to why I am using this goofy structure, it is because building
> a parameterized mux is a little painful if you have to have
> constant bit selects, so I'm forced in to more odd constructions.
>
> On 3/23/12, Stephen Williams <st...@ic...> wrote:
>
>
> There is no breakout[0]. When g==1, your generated assign will be:
>
> assign insel = (rr_state[1]) ? c_data >> (1*width) :
> breakout[0].insel;
>
> but since breakout[0] is not generated, the reference to
> (breakout[0].insel) fails.
>
> On 03/23/2012 03:45 PM, Guy Hutchison wrote:
>>>> But if I recode it as follows:
>>>>
>>>> genvar g;
>>>>
>>>> wire [width-1:0] insel0; assign insel0 = (rr_state[0]) ?
>>>> c_data[width-1:0] : {width{1'b0}}; assign p_srdy = |(rr_state
>>>> & c_srdy);
>>>>
>>>> generate for (g=1; g<inputs; g=g+1) begin : breakout wire
>>>> [width-1:0] insel; assign insel = (rr_state[g]) ? c_data >>
>>>> (g*width) : breakout[g-1].insel; end endgenerate assign
>>>> p_data = breakout[inputs-1].insel;
>>>>
>>>> then I get the error: error: Unable to bind wire/reg/memory
>>>> `breakout[(g)-('sd1)].insel' in
>>>> `env_top.bridge.control0.fib_arb.breakout[1]
>>>>
>>>> At this point everything is clearly constant, although
>>>> icarus complains as above and Verilator complains that it
>>>> can't shift by a non-constant value (width is a parameter).
>>>>
>>>> BTW, this whole rathole was triggered by Verilator
>>>> complaining about the original syntax I have for this being
>>>> unoptimizable due to a for loop.
>>>>
>>>> On 3/23/12, Martin Whitaker
>>>> <mai...@ma...> wrote:
>>>>> I think it's a LRM question. From section 12.5 of the
>>>>> standard
>>>>>
>>>>> "Names in a hierarchical path name that refer to instance
>>>>> arrays or loop generate blocks may be followed immediately
>>>>> by a constant expression in square brackets."
>>>>>
>>>>> Constant expressions are defined in annex A (formal syntax)
>>>>> and are defined to be one or more constant primaries
>>>>> (combined by appropriate operators). A constant primary is
>>>>> defined as
>>>>>
>>>>> constant_primary ::= number | parameter_identifier [ [
>>>>> constant_range_expression ] ] | specparam_identifier [ [
>>>>> constant_range_expression ] ] | constant_concatenation |
>>>>> constant_multiple_concatenation | constant_function_call |
>>>>> constant_system_function_call | (
>>>>> constant_mintypmax_expression ) | string
>>>>>
>>>>> 'j' in your code must be a hierarchical identifier
>>>>> (otherwise you couldn't use it as a loop variable), so is
>>>>> not a valid constant primary.
>>>>>
>>>>> So what you have written is not legal Verilog - even if a
>>>>> synthesis tool accepts it.
>>>>>
>>>>>
>>>>> Guy Hutchison wrote:
>>>>>> Not sure if this is an Icarus question or an LRM
>>>>>> question, but while refactoring some code with generate
>>>>>> statements I ran across this error message:
>>>>>>
>>>>>> sd_rrmux.v:151: error: Scope index expression is not
>>>>>> constant: j
>>>>>>
>>>>>> The code that caused the error was: generate for (i=0;
>>>>>> i<inputs; i=i+1) begin : grid_assign wire [width-1:0]
>>>>>> temp; assign temp = c_data>> (i*width); //assign
>>>>>> rr_mux_grid[i] = c_data>> (i*width); end endgenerate
>>>>>> always @* begin p_data = 0; p_srdy = 0; for (j=0;
>>>>>> j<inputs; j=j+1) if (rr_state[j]) begin //p_data =
>>>>>> rr_mux_grid[j]; p_data = grid_assign[j].temp; p_srdy =
>>>>>> c_srdy[j]; end end
>>>>>>
>>>>>> A synthesis tool has no problem figuring out that j is
>>>>>> constant within the begin-end scope listed here; why is
>>>>>> it not "constant" for picking up a scope reference? This
>>>>>> also fails within a generate loop using a genvar as the
>>>>>> index var.
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>>
>
>>>>>>
This SF email is sponsosred by:
>>>>>> Try Windows Azure free for 90 days Click Here
>>>>>> http://p.sf.net/sfu/sfd2d-msazure
>>>>>> _______________________________________________
>
>
>>
>> ------------------------------------------------------------------------------
>>
>>
This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________ Iverilog-devel
>> mailing list Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>
>
> ------------------------------------------------------------------------------
>
>
This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________ Iverilog-devel
> mailing list Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9tCaoACgkQrPt1Sc2b3im/3wCgq2uzoGn1aok3DFAW1pCoJBLd
uu0AoJmNtOKp0PIJO7h6KrYIJLlyAb8C
=ukKr
-----END PGP SIGNATURE-----
|
|
From: Stephan B. <boe...@ph...> - 2012-03-24 00:11:09
|
I had good results with constructs like this:
wire [width-1:0] insel[0..inputs];
wire [width-1:0] mux = insel[0];
assign insel[inputs]=0;
generate
for (g=0; g<inputs; g=g+1)
assign insel[g] = rr_state[0] ? c_data >> (g*width) : insel[g+1];
endgenerate
Guy Hutchison <ghu...@gm...> writes:
> Good catch by all replies, changing this to:
> generate
> for (g=0; g<inputs; g=g+1)
> begin : breakout
> wire [width-1:0] insel;
> if (g==0)
> assign insel = (rr_state[0]) ? c_data[width-1:0] : {width{1'b0}};
> else
> assign insel = (rr_state[g]) ? c_data >> (g*width) :
> breakout[g-1].insel;
> end
> endgenerate
> assign p_data = breakout[inputs-1].insel;
>
> Fixes the access-zero problem, as zero is the special case.
>
> As to why I am using this goofy structure, it is because building a
> parameterized mux is a little painful if you have to have constant bit
> selects, so I'm forced in to more odd constructions.
>
> On 3/23/12, Stephen Williams <st...@ic...> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> There is no breakout[0]. When g==1, your generated assign will be:
>>
>> assign insel = (rr_state[1]) ? c_data >> (1*width) : breakout[0].insel;
>>
>> but since breakout[0] is not generated, the reference to
>> (breakout[0].insel) fails.
>>
>> On 03/23/2012 03:45 PM, Guy Hutchison wrote:
>>> But if I recode it as follows:
>>>
>>> genvar g;
>>>
>>> wire [width-1:0] insel0; assign insel0 = (rr_state[0]) ?
>>> c_data[width-1:0] : {width{1'b0}}; assign p_srdy = |(rr_state &
>>> c_srdy);
>>>
>>> generate for (g=1; g<inputs; g=g+1) begin : breakout wire
>>> [width-1:0] insel; assign insel = (rr_state[g]) ? c_data >>
>>> (g*width) : breakout[g-1].insel; end endgenerate assign p_data =
>>> breakout[inputs-1].insel;
>>>
>>> then I get the error: error: Unable to bind wire/reg/memory
>>> `breakout[(g)-('sd1)].insel' in
>>> `env_top.bridge.control0.fib_arb.breakout[1]
>>>
>>> At this point everything is clearly constant, although icarus
>>> complains as above and Verilator complains that it can't shift by
>>> a non-constant value (width is a parameter).
>>>
>>> BTW, this whole rathole was triggered by Verilator complaining
>>> about the original syntax I have for this being unoptimizable due
>>> to a for loop.
>>>
>>> On 3/23/12, Martin Whitaker <mai...@ma...>
>>> wrote:
>>>> I think it's a LRM question. From section 12.5 of the standard
>>>>
>>>> "Names in a hierarchical path name that refer to instance arrays
>>>> or loop generate blocks may be followed immediately by a constant
>>>> expression in square brackets."
>>>>
>>>> Constant expressions are defined in annex A (formal syntax) and
>>>> are defined to be one or more constant primaries (combined by
>>>> appropriate operators). A constant primary is defined as
>>>>
>>>> constant_primary ::= number | parameter_identifier [ [
>>>> constant_range_expression ] ] | specparam_identifier [ [
>>>> constant_range_expression ] ] | constant_concatenation |
>>>> constant_multiple_concatenation | constant_function_call |
>>>> constant_system_function_call | ( constant_mintypmax_expression
>>>> ) | string
>>>>
>>>> 'j' in your code must be a hierarchical identifier (otherwise you
>>>> couldn't use it as a loop variable), so is not a valid constant
>>>> primary.
>>>>
>>>> So what you have written is not legal Verilog - even if a
>>>> synthesis tool accepts it.
>>>>
>>>>
>>>> Guy Hutchison wrote:
>>>>> Not sure if this is an Icarus question or an LRM question, but
>>>>> while refactoring some code with generate statements I ran
>>>>> across this error message:
>>>>>
>>>>> sd_rrmux.v:151: error: Scope index expression is not constant:
>>>>> j
>>>>>
>>>>> The code that caused the error was: generate for (i=0;
>>>>> i<inputs; i=i+1) begin : grid_assign wire [width-1:0] temp;
>>>>> assign temp = c_data>> (i*width); //assign rr_mux_grid[i] =
>>>>> c_data>> (i*width); end endgenerate always @* begin p_data =
>>>>> 0; p_srdy = 0; for (j=0; j<inputs; j=j+1) if (rr_state[j])
>>>>> begin //p_data = rr_mux_grid[j]; p_data = grid_assign[j].temp;
>>>>> p_srdy = c_srdy[j]; end end
>>>>>
>>>>> A synthesis tool has no problem figuring out that j is constant
>>>>> within the begin-end scope listed here; why is it not
>>>>> "constant" for picking up a scope reference? This also fails
>>>>> within a generate loop using a genvar as the index var.
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>>
>> This SF email is sponsosred by:
>>>>> Try Windows Azure free for 90 days Click Here
>>>>> http://p.sf.net/sfu/sfd2d-msazure
>>>>> _______________________________________________
>>
>>
>> - --
>> Steve Williams "The woods are lovely, dark and deep.
>> steve at icarus.com But I have promises to keep,
>> http://www.icarus.com and lines to code before I sleep,
>> http://www.picturel.com And lines to code before I sleep."
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.16 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk9tApgACgkQrPt1Sc2b3ikKKwCfRjlS5duvb7qATrYZeWWn7iOo
>> bhkAoNl1TyTu7R+WrkFhv2tw95XRX1ey
>> =EMgA
>> -----END PGP SIGNATURE-----
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
--
Dr. Stephan Böttcher Tel: +49-431-880-2508
Christian-Albrechts-Universität zu Kiel
Inst. f. Exp. u. Angew. Physik, Abt. Extraterrestrische Physik
Leibnizstr. 11, 24118 Kiel, Germany
|
|
From: Martin W. <mai...@ma...> - 2012-03-24 00:20:42
|
Guy Hutchison wrote:
> Good catch by all replies, changing this to:
> generate
> for (g=0; g<inputs; g=g+1)
> begin : breakout
> wire [width-1:0] insel;
> if (g==0)
> assign insel = (rr_state[0]) ? c_data[width-1:0] : {width{1'b0}};
> else
> assign insel = (rr_state[g]) ? c_data>> (g*width) :
> breakout[g-1].insel;
> end
> endgenerate
> assign p_data = breakout[inputs-1].insel;
>
> Fixes the access-zero problem, as zero is the special case.
>
> As to why I am using this goofy structure, it is because building a
> parameterized mux is a little painful if you have to have constant bit
> selects, so I'm forced in to more odd constructions.
You've actually coded a priority encoder. If you really want a mux, it's a
fairly simple change:
generate
for (g=0; g<inputs; g=g+1)
begin : breakout
wire [width-1:0] insel;
wire [width-1:0] out;
assign insel = {width{rr_state[g]}} & c_data[width*g +: width];
if (g==0)
assign out = insel;
else
assign out = insel | breakout[g-1].out;
end
endgenerate
assign p_data = breakout[inputs-1].out;
This should synthesise without any trouble.
If you don't need a one-hot coded select, you can always write:
assign p_data = c_data[rr_index*width +: width];
although I've never tried synthesising a construct like this.
Martin
|
|
From: Guy H. <ghu...@gm...> - 2012-03-24 03:53:39
|
Hi Martin,
Variable bit indexes are not synthesizable, although I have not tried indexes using a generate. If they are supported by synth that would be the most straightforward approach. At present I don't have access to a synthesis tool; I'll have to try this next time one is available.
It's true that it is actually a priority encoder; since bit selects were already available this was easier than an encoded mux.
Guy
On Mar 23, 2012, at 5:20 PM, Martin Whitaker <mai...@ma...> wrote:
> Guy Hutchison wrote:
>> Good catch by all replies, changing this to:
>> generate
>> for (g=0; g<inputs; g=g+1)
>> begin : breakout
>> wire [width-1:0] insel;
>> if (g==0)
>> assign insel = (rr_state[0]) ? c_data[width-1:0] : {width{1'b0}};
>> else
>> assign insel = (rr_state[g]) ? c_data>> (g*width) :
>> breakout[g-1].insel;
>> end
>> endgenerate
>> assign p_data = breakout[inputs-1].insel;
>>
>> Fixes the access-zero problem, as zero is the special case.
>>
>> As to why I am using this goofy structure, it is because building a
>> parameterized mux is a little painful if you have to have constant bit
>> selects, so I'm forced in to more odd constructions.
>
> You've actually coded a priority encoder. If you really want a mux, it's a
> fairly simple change:
>
> generate
> for (g=0; g<inputs; g=g+1)
> begin : breakout
> wire [width-1:0] insel;
> wire [width-1:0] out;
> assign insel = {width{rr_state[g]}} & c_data[width*g +: width];
> if (g==0)
> assign out = insel;
> else
> assign out = insel | breakout[g-1].out;
> end
> endgenerate
> assign p_data = breakout[inputs-1].out;
>
> This should synthesise without any trouble.
>
> If you don't need a one-hot coded select, you can always write:
>
> assign p_data = c_data[rr_index*width +: width];
>
> although I've never tried synthesising a construct like this.
>
> Martin
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
|
From: Cary R. <cy...@ya...> - 2012-03-25 17:04:02
|
I just checked to verify that the chip we taped out a few years ago used variable indexed part selects (the +: version) as a R-value as shown here. I also used one as an L-value. This was using the latest version of Encounter available at the time.
If the construct is supported I would expect the generate version to be the first to be implemented since it can be directly mapped to a part select while the variable version would require some code changes to support a width greater than 1, which is what a variable bit select supports.
Cary
----- Original Message -----
From: Guy Hutchison <ghu...@gm...>
To: Discussions concerning Icarus Verilog development <ive...@li...>
Cc: Discussions concerning Icarus Verilog development <ive...@li...>
Sent: Friday, March 23, 2012 8:53 PM
Subject: Re: [Iverilog-devel] What is a constant?
Hi Martin,
Variable bit indexes are not synthesizable, although I have not tried indexes using a generate. If they are supported by synth that would be the most straightforward approach. At present I don't have access to a synthesis tool; I'll have to try this next time one is available.
It's true that it is actually a priority encoder; since bit selects were already available this was easier than an encoded mux.
Guy
On Mar 23, 2012, at 5:20 PM, Martin Whitaker <mai...@ma...> wrote:
> Guy Hutchison wrote:
>> Good catch by all replies, changing this to:
>> generate
>> for (g=0; g<inputs; g=g+1)
>> begin : breakout
>> wire [width-1:0] insel;
>> if (g==0)
>> assign insel = (rr_state[0]) ? c_data[width-1:0] : {width{1'b0}};
>> else
>> assign insel = (rr_state[g]) ? c_data>> (g*width) :
>> breakout[g-1].insel;
>> end
>> endgenerate
>> assign p_data = breakout[inputs-1].insel;
>>
>> Fixes the access-zero problem, as zero is the special case.
>>
>> As to why I am using this goofy structure, it is because building a
>> parameterized mux is a little painful if you have to have constant bit
>> selects, so I'm forced in to more odd constructions.
>
> You've actually coded a priority encoder. If you really want a mux, it's a
> fairly simple change:
>
> generate
> for (g=0; g<inputs; g=g+1)
> begin : breakout
> wire [width-1:0] insel;
> wire [width-1:0] out;
> assign insel = {width{rr_state[g]}} & c_data[width*g +: width];
> if (g==0)
> assign out = insel;
> else
> assign out = insel | breakout[g-1].out;
> end
> endgenerate
> assign p_data = breakout[inputs-1].out;
>
> This should synthesise without any trouble.
>
> If you don't need a one-hot coded select, you can always write:
>
> assign p_data = c_data[rr_index*width +: width];
>
> although I've never tried synthesising a construct like this.
>
> Martin
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
|
From: Tariq B. A. <tar...@gm...> - 2012-03-24 10:32:01
|
Hi Guy, I hope you are well. You may use synthesis tool in Xilinx to do synthesis. ISE Webpack is free http://www.xilinx.com/support/download/index.htm This thread on edaboard talks about both icarus verilog 0.8 and Xilinx ISE to do synthesis http://www.edaboard.com/thread217079.html#post925328 If you are looking for Synopsys DC, we may talk about it off the thread. Kind Regards, Tariq On Fri, Mar 23, 2012 at 11:53 PM, Guy Hutchison <ghu...@gm...> wrote: > Hi Martin, > > Variable bit indexes are not synthesizable, although I have not tried > indexes using a generate. If they are supported by synth that would be the > most straightforward approach. At present I don't have access to a > synthesis tool; I'll have to try this next time one is available. > > It's true that it is actually a priority encoder; since bit selects were > already available this was easier than an encoded mux. > > Guy > > On Mar 23, 2012, at 5:20 PM, Martin Whitaker < > mai...@ma...> wrote: > > > Guy Hutchison wrote: > >> Good catch by all replies, changing this to: > >> generate > >> for (g=0; g<inputs; g=g+1) > >> begin : breakout > >> wire [width-1:0] insel; > >> if (g==0) > >> assign insel = (rr_state[0]) ? c_data[width-1:0] : {width{1'b0}}; > >> else > >> assign insel = (rr_state[g]) ? c_data>> (g*width) : > >> breakout[g-1].insel; > >> end > >> endgenerate > >> assign p_data = breakout[inputs-1].insel; > >> > >> Fixes the access-zero problem, as zero is the special case. > >> > >> As to why I am using this goofy structure, it is because building a > >> parameterized mux is a little painful if you have to have constant bit > >> selects, so I'm forced in to more odd constructions. > > > > You've actually coded a priority encoder. If you really want a mux, it's > a > > fairly simple change: > > > > generate > > for (g=0; g<inputs; g=g+1) > > begin : breakout > > wire [width-1:0] insel; > > wire [width-1:0] out; > > assign insel = {width{rr_state[g]}} & c_data[width*g +: width]; > > if (g==0) > > assign out = insel; > > else > > assign out = insel | breakout[g-1].out; > > end > > endgenerate > > assign p_data = breakout[inputs-1].out; > > > > This should synthesise without any trouble. > > > > If you don't need a one-hot coded select, you can always write: > > > > assign p_data = c_data[rr_index*width +: width]; > > > > although I've never tried synthesising a construct like this. > > > > Martin > > > > > ------------------------------------------------------------------------------ > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > _______________________________________________ > > Iverilog-devel mailing list > > Ive...@li... > > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > |
|
From: Iztok J. <izt...@gm...> - 2012-03-24 15:23:42
|
There are two other free synthesis tools: Altera Quartus II (also supports some SystemVerilog) Lattice Diamond (synplify from Synopsys is used for synthesis, synplify outputs useful warnings) Regards, Iztok Jeras On Sat, Mar 24, 2012 at 11:31, Tariq Bashir Ahmad <tar...@gm...> wrote: > Hi Guy, > > I hope you are well. You may use synthesis tool in Xilinx to do synthesis. > ISE Webpack is free > > http://www.xilinx.com/support/download/index.htm > > This thread on edaboard talks about both icarus verilog 0.8 and Xilinx ISE > to do synthesis > > http://www.edaboard.com/thread217079.html#post925328 > > > If you are looking for Synopsys DC, we may talk about it off the thread. > > Kind Regards, > Tariq > > > > On Fri, Mar 23, 2012 at 11:53 PM, Guy Hutchison <ghu...@gm...> wrote: >> >> Hi Martin, >> >> Variable bit indexes are not synthesizable, although I have not tried >> indexes using a generate. If they are supported by synth that would be the >> most straightforward approach. At present I don't have access to a >> synthesis tool; I'll have to try this next time one is available. >> >> It's true that it is actually a priority encoder; since bit selects were >> already available this was easier than an encoded mux. >> >> Guy >> >> On Mar 23, 2012, at 5:20 PM, Martin Whitaker >> <mai...@ma...> wrote: >> >> > Guy Hutchison wrote: >> >> Good catch by all replies, changing this to: >> >> generate >> >> for (g=0; g<inputs; g=g+1) >> >> begin : breakout >> >> wire [width-1:0] insel; >> >> if (g==0) >> >> assign insel = (rr_state[0]) ? c_data[width-1:0] : {width{1'b0}}; >> >> else >> >> assign insel = (rr_state[g]) ? c_data>> (g*width) : >> >> breakout[g-1].insel; >> >> end >> >> endgenerate >> >> assign p_data = breakout[inputs-1].insel; >> >> >> >> Fixes the access-zero problem, as zero is the special case. >> >> >> >> As to why I am using this goofy structure, it is because building a >> >> parameterized mux is a little painful if you have to have constant bit >> >> selects, so I'm forced in to more odd constructions. >> > >> > You've actually coded a priority encoder. If you really want a mux, it's >> > a >> > fairly simple change: >> > >> > generate >> > for (g=0; g<inputs; g=g+1) >> > begin : breakout >> > wire [width-1:0] insel; >> > wire [width-1:0] out; >> > assign insel = {width{rr_state[g]}} & c_data[width*g +: width]; >> > if (g==0) >> > assign out = insel; >> > else >> > assign out = insel | breakout[g-1].out; >> > end >> > endgenerate >> > assign p_data = breakout[inputs-1].out; >> > >> > This should synthesise without any trouble. >> > >> > If you don't need a one-hot coded select, you can always write: >> > >> > assign p_data = c_data[rr_index*width +: width]; >> > >> > although I've never tried synthesising a construct like this. >> > >> > Martin >> > >> > >> > ------------------------------------------------------------------------------ >> > This SF email is sponsosred by: >> > Try Windows Azure free for 90 days Click Here >> > http://p.sf.net/sfu/sfd2d-msazure >> > _______________________________________________ >> > Iverilog-devel mailing list >> > Ive...@li... >> > https://lists.sourceforge.net/lists/listinfo/iverilog-devel >> >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> Iverilog-devel mailing list >> Ive...@li... >> https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > |
|
From: Martin W. <mai...@ma...> - 2012-03-24 19:11:26
|
Hi Guy, Guy Hutchison wrote: > Variable bit indexes are not synthesizable, although I have not tried > indexes using a generate. If they are supported by synth that would be the > most straightforward approach. At present I don't have access to a > synthesis tool; I'll have to try this next time one is available. > I got curious, and tried this out in DC. It accepts assign p_data = c_data[select*width +: width]; and maps it to generic SELECT_OP cells (so will either map to a mux or and/or implementation, as DC sees fit). I'm using the latest release of DC, so it may be this feature has only been added recently. I've been using indexes based on a genvar for some years, so know that Synopsys, Cadence, Altera, and Xilinx synthesis tools all support this. > It's true that it is actually a priority encoder; since bit selects were > already available this was easier than an encoded mux. > Using the alternative coding I suggested gives a smaller/faster implementation in my experience. Martin |
|
From: Guy H. <ghu...@gm...> - 2012-03-24 20:33:44
|
Hi Martin, Thanks for pointing this out; this is a much cleaner technique. I've been gradually putting more systemverilog constructs in to my code over the years but hadn't bothered to check on this. Thanks, Guy On 3/24/12, Martin Whitaker <mai...@ma...> wrote: > Hi Guy, > > Guy Hutchison wrote: >> Variable bit indexes are not synthesizable, although I have not tried >> indexes using a generate. If they are supported by synth that would be >> the >> most straightforward approach. At present I don't have access to a >> synthesis tool; I'll have to try this next time one is available. >> > I got curious, and tried this out in DC. It accepts > > assign p_data = c_data[select*width +: width]; > > and maps it to generic SELECT_OP cells (so will either map to a mux or > and/or > implementation, as DC sees fit). I'm using the latest release of DC, so it > may > be this feature has only been added recently. > > I've been using indexes based on a genvar for some years, so know that > Synopsys, Cadence, Altera, and Xilinx synthesis tools all support this. > >> It's true that it is actually a priority encoder; since bit selects were >> already available this was easier than an encoded mux. >> > Using the alternative coding I suggested gives a smaller/faster > implementation > in my experience. > > Martin > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X