Electronic – vhdl port declaration with different sizes

vhdlxilinx

I'm writing a vhdl model and I'm stuck with a problem about port declaration.
Let's say that I have an entity entityA that instantiates N entityB. Now, entityB has a port, out, with size M bits, and M can vary among all entities, so out is std_logic_vector(M-1 downto 0). These ports need to be propagated outsize entityB.

If all entityB components would have the same port size, say FIX_M, the solution would be to use a std_logic_vector(N*FIX_M-1 downto 0) in entityA. My problem is that the size M can vary. The first solution that comes to my mind is to use the same solution, using instead of M a MAX_M, but in that case a lot of pins would be left unused (and for input it is a problem, right?).

Do you have a better idea?
Thank you in advance.

Best Answer

It uses an array of sizes to specify the individual sizes of EntityB. The port of EntityA has the size calculated by sum.

The matching bits are sliced by high and low.

global function:

function sum(SIZES) is
  variable count : integer := 0;
begin
  for i in SIZES'range loop
    count := count + SIZES(i);
  end loop;
  return count;
end function;

Example:

entity EntityA is
  genierc (
    SIZES : integer_vector
  );
  port (
    data(sum(SIZES) - 1 downto 0)
  );
end entity;

architecture rtl of EntityA is
  function high(SIZES, idx) is
  begin
    for i in 0 to idx loop
      pos := pos + SIZES(i);
    end loop;
    return pos - 1;
  end function;
  function low(SIZES, idx) is
  begin
    for i in 0 to idx - 1 loop
      pos := pos + SIZES(i);
    end loop;
    return pos;
  end function;
begin
  genB : for i in SIZES'range generate
    instB : entity work.EntityB
      generic map (
        N => SIZES(i)
      )
      port map (
        data => data(high(SIZES, i) downto low(SIZES, i))
      );
end architecture;

Usage:

signal input : std_logic_vector(13 downto 0);

ex : entity work.EntityA
  generic map (
    SIZES => (2, 3, 4, 5)
  );
  port map (
    data => input
  );

Related Solutions

Electronic – VHDL ‘buffer’ vs. ‘out’

One case, that probably doesn't apply, is if you're using a standard older than VHDL-2002. Before than, buffer could not connect directly to out. So in a hierarchical design, the signal path would need to be declared as a buffer on all levels. Also, when adhering to these older standards, some tools have problems synthesizing buffers correctly. They may or may not warn you about this.

These should no longer be an issue if you're using a newer standard. From the VHDL-2002 Standard:

a) For a formal port of mode in, the associated actual must be a port of mode in, inout, or buffer.

b) For a formal port of mode out, the associated actual must be a port of mode out, inout, or buffer.

c) For a formal port of mode inout, the associated actual must be a port of mode inout, or buffer.

d) For a formal port of mode buffer, the associated actual must be a port of mode out, inout, or buffer.

e) For a formal port of mode linkage, the associated actual may be a port of any mode.

I also often see advice stating that a buffer should never be tri-stated. If you need the ability to tri-state a bus, then you would need to use out. I could find no direct reference to how buffers handled tri-stating in the standard. But it is probably good advice to follow. Again, your tools may or may not complain if you attempt to synthesis a tri-stated buffer.

Electronic – Why does VHDL function declaration not accept bounds for the return type, e.g. std_logic_vector

This is mostly for Jonathan Drolet but there's also a lesson here. Note that parameter argument to my_function supplies a type mark with a subtype indication. This is valid in VHDL.

library ieee;
use ieee.std_logic_1164.all;

entity myfunc is
end entity;

architecture foo of myfunc is
    function my_function(lv: std_logic_vector(3 downto 0)) 
            return std_logic_vector is  
    begin 
    return lv & "000";
    end function;

    constant fumble:  std_logic_vector (3 downto 0) := x"E";
    signal humble:    std_logic_vector (6 downto 0);
begin
    humble <= my_function(fumble);

end architecture;

This code analyzes, elaborates and simulates.

Note that the return mark is an unconstrained subtype and the result value is assigned to a declared signal with a subtype indication (supplying an index constraint).

There are rules specifically for determining the effective value of a signal that require the bounds be checked after an implicit subtype conversion. Providing a return value that doesn't match the bounds of humble would result in a run time error causing simulation to end without successfully completing.

In other words a constraint isn't necessary here. The return value subtype indication is derived internally, and as is shown in this from the input parameter.

Best Answer

Related Solutions

Electronic – VHDL ‘buffer’ vs. ‘out’

Electronic – Why does VHDL function declaration not accept bounds for the return type, e.g. std_logic_vector

Related Topic