Unconstrained array ports - Good or Bad?

Discussion in 'VHDL' started by Anon Anon, Jan 28, 2007.

  1. Anon Anon

    Anon Anon Guest

    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, Jan 28, 2007
    #1
    1. Advertising

  2. 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, Jan 28, 2007
    #2
    1. Advertising

  3. Anon Anon

    Anon Anon Guest

    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, Jan 28, 2007
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mohammed  A khader

    Unconstrained ports for synthesis

    Mohammed A khader, Apr 20, 2005, in forum: VHDL
    Replies:
    5
    Views:
    1,019
    Ray Andraka
    Apr 22, 2005
  2. Amal
    Replies:
    5
    Views:
    8,623
    Brandon
    Mar 8, 2006
  3. jens
    Replies:
    3
    Views:
    814
  4. mreister
    Replies:
    1
    Views:
    3,112
    mreister
    May 25, 2010
  5. rantingrick
    Replies:
    44
    Views:
    1,161
    Peter Pearson
    Jul 13, 2010
Loading...

Share This Page