Unconstrained array ports - Good or Bad?

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 and other reports I've read on the topic seem to indicate
either implicitly or explicitly that they are a Very Bad Thing.

Can the experts who visit this newsgroup provide some insight to clarify
the position?

Thanks!

Anon Anon

On Sun, 28 Jan 2007 18:08:57 +0000, Anon Anon <> wrote:

>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

http://www.MYCOMPANY.com

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

Jonathan Bromley

Jonathan Bromley wrote:
> On Sun, 28 Jan 2007 18:08:57 +0000, Anon Anon <> wrote:
>
>> 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.

Thanks for your feedback, which sort-of confirms my own feeling, that
they really *are* a good feature. Incidentally, (hint) I do actually use
them in my other current posting, which relates to some problems I'm
having with the Xilinx Floating-Point IP

Unfortunately, I can't pin-down the site which criticised them - but
I've looked at so many sites in the past few days it's hard to remember
where I've been!

Thanks

Anon Anon