Unconstrained array ports - Good or Bad?

[Anon Anon]

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!

 

[Jonathan Bromley]

On Sun, 28 Jan 2007 18:08:57 +0000, Anon Anon <anon@anon.net> 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
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.

 

[Anon Anon]

Jonathan Bromley wrote:

On Sun, 28 Jan 2007 18:08:57 +0000, Anon Anon <anon@anon.net> 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