Xilinx XST 9.1, Verilog 2-D arrays, always @*

I noticed XST 9.1 still doesn't support multi-dim arrays in an always @* 
block.
Here's a (perhaps poor) example:

reg  signed [15:0] table [0:255];
reg  signed [23:0] sum;

integer i;
always @*
begin
  sum = 0;
  for ( i =0; i < 256; i = i + 1 )
    sum = sum + table[i];  // yes, I know this will synthesize a suboptimal 
imbalanced adder-tree!
end 

On 3=D4=C217=C8=D5, =CF=C2=CE=E72=CA=B128=B7=D6, "Ulsk" <a...@ljs.com> wrot=
e:
> I noticed XST 9.1 still doesn't support multi-dim arrays in an always @*
> block.
> Here's a (perhaps poor) example:
>
> reg  signed [15:0] table [0:255];
> reg  signed [23:0] sum;
>
> integer i;
> always @*
> begin
>   sum =3D 0;
>   for ( i =3D0; i < 256; i =3D i + 1 )
>     sum =3D sum + table[i];  // yes, I know this will synthesize a subopt=
imal
> imbalanced adder-tree!
> end

I think the code can not be synthesize correctly by any tool not only
ISE!

> "Homuncilus" <Sha.Craig@gmail.com> wrote in message 
> news:1174121624.193180.150560@n59g2000hsh.googlegroups.com...
> On 3??17&#4294967295;&#4294967295;?, ????2&#4294967295;&#4294967295;&#4294967295;&#4294967295;28&#4294967295;&#4294967295;?, "Ulsk" <a...@ljs.com> wrote:
> I noticed XST 9.1 still doesn't support multi-dim arrays in an always @*
> > block.
> > Here's a (perhaps poor) example:
> >
> > reg  signed [15:0] table [0:255];
> > reg  signed [23:0] sum;
> >
> > integer i;
> > always @*
> > begin
> >   sum = 0;
> >   for ( i =0; i < 256; i = i + 1 )
> >     sum = sum + table[i];  // yes, I know this will synthesize a 
> > suboptimal
> > imbalanced adder-tree!
> > end
>
> I think the code can not be synthesize correctly by any tool not only
> ISE!

ASIC synthesis tools (like Synopsys Design Compiler, Cadence RTL
Compiler, etc.) have no difficulty synthesizing the above example. 

On 3=E6=9C=8818=E6=97=A5, =E4=B8=8A=E5=8D=886=E6=97=B617=E5=88=86, "Ulsk" <=
a=2E..@ljs.com> wrote:
> > "Homuncilus" <Sha.Cr...@gmail.com> wrote in message
> >news:1174121624.193180.150560@n59g2000hsh.googlegroups.com...
> > On 3??17=C2=A8=C2=A8?, ????2=C2=A8=C2=BA=C2=A1=C3=8028=C2=A1=C2=A4?, "U=
lsk" <a...@ljs.com> wrote:
> > I noticed XST 9.1 still doesn't support multi-dim arrays in an always @*
> > > block.
> > > Here's a (perhaps poor) example:
>
> > > reg =C2=A0signed [15:0] table [0:255];
> > > reg =C2=A0signed [23:0] sum;
>
> > > integer i;
> > > always @*
> > > begin
> > > =C2=A0 sum =3D 0;
> > > =C2=A0 for ( i =3D0; i < 256; i =3D i + 1 )
> > > =C2=A0 =C2=A0 sum =3D sum + table[i]; =C2=A0// yes, I know this will =
synthesize a
> > > suboptimal
> > > imbalanced adder-tree!
> > > end
>
> > I think the code can not be synthesize correctly by any tool not only
> > ISE!
>
> ASIC synthesis tools (like Synopsys Design Compiler, Cadence RTL
> Compiler, etc.) have no difficulty synthesizing the above example.- =E9=
=9A=90=E8=97=8F=E8=A2=AB=E5=BC=95=E7=94=A8=E6=96=87=E5=AD=97 -
>
> - =E6=98=BE=E7=A4=BA=E5=BC=95=E7=94=A8=E7=9A=84=E6=96=87=E5=AD=97 -

Could you tell me the result about the above example being synthesized
by the ASIC tools and could you sure that the function runs well?

On Mar 16, 11:28 pm, "Ulsk" <a...@ljs.com> wrote:
> I noticed XST 9.1 still doesn't support multi-dim arrays in an always @*
> block.
> Here's a (perhaps poor) example:
>
> reg  signed [15:0] table [0:255];
> reg  signed [23:0] sum;
>
> integer i;
> always @*
> begin
>   sum = 0;
>   for ( i =0; i < 256; i = i + 1 )
>     sum = sum + table[i];  // yes, I know this will synthesize a suboptimal
> imbalanced adder-tree!
> end

Correct me if I'm wrong, but I believe that this is not valid verilog
- you cannot use an array as a term in the always() sensitivity list,
and the always* implies that the array is in the sensitivity list. I
know that the ncverilog simulator warns about this (but does work). It
states that this is non-portable verilog. Synopsys DC does indeed
synthesize this correctly, but it's not a good idea to use non-
standard verilog statements. ISE seems to err on the side of adhering
to the strict rules of the verilog language. I could be wrong about
this, but from the warning given by ncverilog, I believe this to be
the case. Maybe try a verilog linting tool? formality/conformal should
set you straight, if you have them.
Cheers
John

On Mar 19, 11:00 am, "John McGrath" <tail...@gmail.com> wrote:
> On Mar 16, 11:28 pm, "Ulsk" <a...@ljs.com> wrote:
>
> > I noticed XST 9.1 still doesn't support multi-dim arrays in an always @*
> > block.
> > Here's a (perhaps poor) example:
>
> > reg  signed [15:0] table [0:255];
> > reg  signed [23:0] sum;
>
> > integer i;
> > always @*
> > begin
> >   sum = 0;
> >   for ( i =0; i < 256; i = i + 1 )
> >     sum = sum + table[i];  // yes, I know this will synthesize a suboptimal
> > imbalanced adder-tree!
> > end
>
> Correct me if I'm wrong, but I believe that this is not valid verilog
> - you cannot use an array as a term in the always() sensitivity list,
> and the always* implies that the array is in the sensitivity list. I
> know that the ncverilog simulator warns about this (but does work). It
> states that this is non-portable verilog. Synopsys DC does indeed
> synthesize this correctly, but it's not a good idea to use non-
> standard verilog statements. ISE seems to err on the side of adhering
> to the strict rules of the verilog language. I could be wrong about
> this, but from the warning given by ncverilog, I believe this to be
> the case. Maybe try a verilog linting tool? formality/conformal should
> set you straight, if you have them.
> Cheers
> John

I think the wrong isn't due to the sensitivity list. Do you sure the
error in ISE is caused by that?

On Mar 19, 6:59 am, "Homuncilus" <Sha.Cr...@gmail.com> wrote:
> On Mar 19, 11:00 am, "John McGrath" <tail...@gmail.com> wrote:
>
>
>
> > On Mar 16, 11:28 pm, "Ulsk" <a...@ljs.com> wrote:
>
> > > I noticed XST 9.1 still doesn't support multi-dim arrays in an always @*
> > > block.
> > > Here's a (perhaps poor) example:
>
> > > reg  signed [15:0] table [0:255];
> > > reg  signed [23:0] sum;
>
> > > integer i;
> > > always @*
> > > begin
> > >   sum = 0;
> > >   for ( i =0; i < 256; i = i + 1 )
> > >     sum = sum + table[i];  // yes, I know this will synthesize a suboptimal
> > > imbalanced adder-tree!
> > > end
>
> > Correct me if I'm wrong, but I believe that this is not valid verilog
> > - you cannot use an array as a term in the always() sensitivity list,
> > and the always* implies that the array is in the sensitivity list. I
> > know that the ncverilogsimulatorwarns about this (but does work). It
> > states that this is non-portable verilog. Synopsys DC does indeed
> > synthesize this correctly, but it's not a good idea to use non-
> > standard verilog statements.ISEseems to err on the side of adhering
> > to the strict rules of the verilog language. I could be wrong about
> > this, but from the warning given by ncverilog, I believe this to be
> > the case. Maybe try a verilog linting tool? formality/conformal should
> > set you straight, if you have them.
> > Cheers
> > John
>
> I think the wrong isn't due to the sensitivity list. Do you sure the
> error inISEis caused by that?

Hi,

This is something that was supposed to be supported in ISE XST in
9.1i, although the change did not make it in time.

Thanks
Duth

On Mar 19, 5:59 am, "Homuncilus" <Sha.Cr...@gmail.com> wrote:
> On Mar 19, 11:00 am, "John McGrath" <tail...@gmail.com> wrote:
>
>
>
> > On Mar 16, 11:28 pm, "Ulsk" <a...@ljs.com> wrote:
>
> > > I noticed XST 9.1 still doesn't support multi-dim arrays in an always @*
> > > block.
> > > Here's a (perhaps poor) example:
>
> > > reg  signed [15:0] table [0:255];
> > > reg  signed [23:0] sum;
>
> > > integer i;
> > > always @*
> > > begin
> > >   sum = 0;
> > >   for ( i =0; i < 256; i = i + 1 )
> > >     sum = sum + table[i];  // yes, I know this will synthesize a suboptimal
> > > imbalanced adder-tree!
> > > end
>
> > Correct me if I'm wrong, but I believe that this is not valid verilog
> > - you cannot use an array as a term in the always() sensitivity list,
> > and the always* implies that the array is in the sensitivity list. I
> > know that the ncverilog simulator warns about this (but does work). It
> > states that this is non-portable verilog. Synopsys DC does indeed
> > synthesize this correctly, but it's not a good idea to use non-
> > standard verilog statements. ISE seems to err on the side of adhering
> > to the strict rules of the verilog language. I could be wrong about
> > this, but from the warning given by ncverilog, I believe this to be
> > the case. Maybe try a verilog linting tool? formality/conformal should
> > set you straight, if you have them.
> > Cheers
> > John
>
> I think the wrong isn't due to the sensitivity list. Do you sure the
> error in ISE is caused by that?

I ran the following testcase through ncverilog:

module test;

reg [7:0] array [0:7];
reg [2:0] idx;
reg [7:0] out;

always@*
begin
	out = array[idx];
end

endmodule


The logfile gives the following warnings:

always@*
      |
ncvlog: *W,STARMR (array.v,8|6): @* containing memory reference not
standard or portable.
        out = array[idx];
ncvlog: *W,MRSTAR (array.v,10|11): memory reference that was not
standard in @*.
        module worklib.test:v

So clearly always @* when used with an array is non part of the
verilog standard.

Cheers
John

On Mar 19, 7:31 am, "John McGrath" <tail...@gmail.com> wrote:
> On Mar 19, 5:59 am, "Homuncilus" <Sha.Cr...@gmail.com> wrote:
>
>
>
> > On Mar 19, 11:00 am, "John McGrath" <tail...@gmail.com> wrote:
>
> > > On Mar 16, 11:28 pm, "Ulsk" <a...@ljs.com> wrote:
>
> > > > I noticed XST 9.1 still doesn't support multi-dim arrays in an always @*
> > > > block.
> > > > Here's a (perhaps poor) example:
>
> > > > reg  signed [15:0] table [0:255];
> > > > reg  signed [23:0] sum;
>
> > > > integer i;
> > > > always @*
> > > > begin
> > > >   sum = 0;
> > > >   for ( i =0; i < 256; i = i + 1 )
> > > >     sum = sum + table[i];  // yes, I know this will synthesize a suboptimal
> > > > imbalanced adder-tree!
> > > > end
>
> > > Correct me if I'm wrong, but I believe that this is not valid verilog
> > > - you cannot use an array as a term in the always() sensitivity list,
> > > and the always* implies that the array is in the sensitivity list. I
> > > know that the ncverilog simulator warns about this (but does work). It
> > > states that this is non-portable verilog. Synopsys DC does indeed
> > > synthesize this correctly, but it's not a good idea to use non-
> > > standard verilog statements. ISE seems to err on the side of adhering
> > > to the strict rules of the verilog language. I could be wrong about
> > > this, but from the warning given by ncverilog, I believe this to be
> > > the case. Maybe try a verilog linting tool? formality/conformal should
> > > set you straight, if you have them.
> > > Cheers
> > > John
>
> > I think the wrong isn't due to the sensitivity list. Do you sure the
> > error in ISE is caused by that?
>
> I ran the following testcase through ncverilog:
>
> module test;
>
> reg [7:0] array [0:7];
> reg [2:0] idx;
> reg [7:0] out;
>
> always@*
> begin
>         out = array[idx];
> end
>
> endmodule
>
> The logfile gives the following warnings:
>
> always@*
>       |
> ncvlog: *W,STARMR (array.v,8|6): @* containing memory reference not
> standard or portable.
>         out = array[idx];
> ncvlog: *W,MRSTAR (array.v,10|11): memory reference that was not
> standard in @*.
>         module worklib.test:v
>
> So clearly always @* when used with an array is non part of the
> verilog standard.
>
> Cheers
> John


You could alternately use:

always @(idx) in place of always@*

On Mar 19, 7:35 am, "bluesclues" <deepak.l...@gmail.com> wrote:
> On Mar 19, 7:31 am, "John McGrath" <tail...@gmail.com> wrote:
>
>
>
> > On Mar 19, 5:59 am, "Homuncilus" <Sha.Cr...@gmail.com> wrote:
>
> > > On Mar 19, 11:00 am, "John McGrath" <tail...@gmail.com> wrote:
>
> > > > On Mar 16, 11:28 pm, "Ulsk" <a...@ljs.com> wrote:
>
> > > > > I noticed XST 9.1 still doesn't support multi-dim arrays in an always @*
> > > > > block.
> > > > > Here's a (perhaps poor) example:
>
> > > > > reg  signed [15:0] table [0:255];
> > > > > reg  signed [23:0] sum;
>
> > > > > integer i;
> > > > > always @*
> > > > > begin
> > > > >   sum = 0;
> > > > >   for ( i =0; i < 256; i = i + 1 )
> > > > >     sum = sum + table[i];  // yes, I know this will synthesize a suboptimal
> > > > > imbalanced adder-tree!
> > > > > end
>
> > > > Correct me if I'm wrong, but I believe that this is not valid verilog
> > > > - you cannot use an array as a term in the always() sensitivity list,
> > > > and the always* implies that the array is in the sensitivity list. I
> > > > know that the ncverilog simulator warns about this (but does work). It
> > > > states that this is non-portable verilog. Synopsys DC does indeed
> > > > synthesize this correctly, but it's not a good idea to use non-
> > > > standard verilog statements. ISE seems to err on the side of adhering
> > > > to the strict rules of the verilog language. I could be wrong about
> > > > this, but from the warning given by ncverilog, I believe this to be
> > > > the case. Maybe try a verilog linting tool? formality/conformal should
> > > > set you straight, if you have them.
> > > > Cheers
> > > > John
>
> > > I think the wrong isn't due to the sensitivity list. Do you sure the
> > > error in ISE is caused by that?
>
> > I ran the following testcase through ncverilog:
>
> > module test;
>
> > reg [7:0] array [0:7];
> > reg [2:0] idx;
> > reg [7:0] out;
>
> > always@*
> > begin
> >         out = array[idx];
> > end
>
> > endmodule
>
> > The logfile gives the following warnings:
>
> > always@*
> >       |
> > ncvlog: *W,STARMR (array.v,8|6): @* containing memory reference not
> > standard or portable.
> >         out = array[idx];
> > ncvlog: *W,MRSTAR (array.v,10|11): memory reference that was not
> > standard in @*.
> >         module worklib.test:v
>
> > So clearly always @* when used with an array is non part of the
> > verilog standard.
>
> > Cheers
> > John
>
> You could alternately use:
>
> always @(idx) in place of always@*

Maybe, but it would not work if the contents of the array were updated
by a different process, independent of idx.
I'm not sure how this would be syntesized - It may infer latches on
the output, or error out. I'd be interested to see what happens

Personally, for this example (asynch read of array elements) I'd use a
continuous assignment.

But personally I think verilog language should support @* in an array
context, it works in all other contexts, and prevents unintentional
latch inferral.
As we can see from Duth, this will be added to ISE soon, and some
other tools support it too, but they just warn that it is not strictly
part of the standard.

Cheers
John