asserting range / bounds of reg array in Verilog

[nachumk]

In VHDL I can declare an integer with a range helping the compiler to
know if I'm out of bounds in an array access. For example:

signal enable : std_logic_vector(5 downto 0);
signal enable_index : integer range 0 to 5;

ei : in std_logic_vector(2 downto 0);
enable_index <= ei;
enable[ei] <= 1;

The compiler knows that ei won't be out of bounds from the range
declaration.

For Verilog I declare:
reg [5:0] enable;
reg [2:0] enable_index;

Is there anyway to tell Verilog the bounds of enable_index? Perhaps an
assert type statement? Would the best solution be a function that
limits top bound of reg array? Most synthesizers seem to be OK without
the bounds, but I've found that XST has some issues with this.

Thanx,
Nachum Kanovsky

 

[Jonathan Bromley]

On Sun, 30 Aug 2009 02:12:42 -0700 (PDT), nachumk wrote:

enable;
reg [2:0] enable_index;

Is there anyway to tell Verilog the bounds of enable_index? Perhaps an
assert type statement? Would the best solution be a function that
limits top bound of reg array? Most synthesizers seem to be OK without
the bounds, but I've found that XST has some issues with this.

Many synthesis tools will issue a warning if you make any
access to enable[enable_index], because - as you say - the
range of enable_index might fall outside the array bounds.
However, that's a static check that may be performed by
a synth tool; Verilog itself is completely happy for you
to make out-of-bounds array accesses. If you try to read
enable[6] in simulation you will get 1'bx; if you write
to it, it's a no-operation. So you're right; if you're
worried about this, you should add a simulation-only check
whenever you make an access to enable[enable_index].
If your tools support SystemVerilog assertions, you can
use them to make the check more elegant and self-evident.

Such a check will not get rid of any synthesis warnings,
however. It merely allows you to detect, in simulation,
any bad behaviour by the design that puts a value on
enable_index.

Altrnatively it might be better to make the enable[] array
have 8 elements, and tie off the unused elements to zero.
That will bullet-proof your design, and will remove the
synthesis warnings. And a sufficiently smart synthesis
tool may well be able to detect that enable_index cannot
go outside the range 0 to 5 (perhaps because it's driven
from some logic that cannot give it values outside that
range); if so, the tie-to-zero and associated logic will
be optimized away in synthesis.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Andy]

On Aug 30, 4:12 am, nachumk <nach...@gmail.com> wrote:

In VHDL I can declare an integer with a range helping the compiler to
know if I'm out of bounds in an array access. For example:

signal enable : std_logic_vector(5 downto 0);
signal enable_index : integer range 0 to 5;

ei : in std_logic_vector(2 downto 0);
enable_index <= ei;
enable[ei] <= 1;

The compiler knows that ei won't be out of bounds from the range
declaration.

For Verilog I declare:
reg [5:0] enable;
reg [2:0] enable_index;

Is there anyway to tell Verilog the bounds of enable_index? Perhaps an
assert type statement? Would the best solution be a function that
limits top bound of reg array? Most synthesizers seem to be OK without
the bounds, but I've found that XST has some issues with this.

Thanx,
Nachum Kanovsky

Maybe you meant:

signal enable : std_logic_vector(5 downto 0);
signal enable_index : integer range 0 to 5;

ei : in std_logic_vector(2 downto 0);
-- enable_index <= ei;
enable_index <= to_integer(unsigned(ei));
-- enable[ei] <= 1;
enable(enable_index) <= 1;

There are two checks performed: when ei is converted and stored into
enable_index, and when enable_index is used to index enable. The
latter may be optimized to a static, compile-time-only check (given
the subtype's range declaration).

Andy