As a newbie to this area I am confused as to the status/views on
unconstrained array ports.
They appear to be legal, in the VHDL language and "The Designers Guide
to VHDL" by Peter Ashenden makes them out to be a great thing for
producing re-usable entities. However, the Xilinx synthesizer does not
allow them
I don't know where you get the idea that XST can't do unconstrained
vector ports. Any synthesiser with a sensible understanding of VHDL
will handle them.
Of course, you can't put unconstrained ports on your top-level
entity, because you're not connecting anything to the port that
would specify its vector range. Within a design, though, they
can make some simple modules much easier to code. Try this...
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.numeric_std.ALL;
entity decoder is
port (
code: in std_logic_vector;
onehot: out std_logic_vector
);
end decoder;
architecture RTL of decoder is
begin
assert onehot'length = 2**code'length; -- avoid abuse
process(code)
begin
onehot <= (onehot'range=>'0');
onehot(to_integer(unsigned(code))) <= '1';
end process;
end RTL;
Now we have a decoder, we can make use of it in an
enclosing module:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity decoder3to8 is
port (
code : in std_logic_vector(2 downto 0);
onehot: out std_logic_vector(7 downto 0)
);
end decoder3to8;
architecture RTL of decoder3to8 is
begin
the_decoder: entity work.decoder port map (code, onehot);
end RTL;
No problem for XST.
and other reports I've read on the topic seem to indicate
either implicitly or explicitly that they are a Very Bad Thing.
Really? Do they offer any cogent reasoning to support
their position? Or are they just creating apologia for some
tool that doesn't know how to handle this immensely
useful construct?
Note that many of the more interesting uses for
unconstrained *ports*can be more cleanly coded
by using unconstrained *function parameters*.
Synthesis tools that lack support for unconstrained
ports typically atone for their sins by
supporting unconstrained function parameters.
--
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
(e-mail address removed)
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
