cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
409 Views
Registered: ‎07-14-2015

VHDL 2008 width mismatch on multiple instantiations

Hi,

I am facing issue with usage of the 3D array in Vivado. I have two instantiations of the same component. I've used the unconstrained arrays. But somehow, the array dimensions of the first instantiation is affecting the second instantiation. I've made a very minimal reproducible project from my original design. I've attached the .zip file. Any help with this is highly appreciated. 

 

[Synth 8-549] port width mismatch for port 'KERNEL_OUT[0][0][0]': port width = 16, actual width = 32 ["C:/project_1/src/top.vhd":30]

As we can in the code, line #30 is KERNEL_OUT => KernelInt2 and KernelInt2  is actually 32 bits. KernelInt1 is 16bits, but this is not connected to this instance. 

0 Kudos
6 Replies
Highlighted
Teacher
Teacher
376 Views
Registered: ‎07-09-2009

? MatrixStdVectorTp is a two dimension array
yet you are setting it as a 4 dimension array
signal KernelInt1 : MatrixStdVectorTp(0 to 0)(0 to 4)(0 to 4)(15 downto 0);
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Adventurer
Adventurer
375 Views
Registered: ‎07-14-2015

@drjohnsmith MatrixStdVectorTp is 3D with std_logic_vector and 4D with std_logic

 

type StdVectorArrayTp is array (integer range <>) of std_logic_vector;

type MultiStdVectorArrayTp is array(natural range<>) of StdVectorArrayTp;
type MatrixStdVectorTp is array(natural range<>) of MultiStdVectorArrayTp;

0 Kudos
Highlighted
Explorer
Explorer
351 Views
Registered: ‎01-27-2008

@rakend_r 

Haven't used VHDL in a while but, did you specify the file as VHDL2008?

I think it would work as VHDL2008.

If not, perhaps use a generic to pin the slv size down, reusing per 16b / 32b?

0 Kudos
Highlighted
Adventurer
Adventurer
281 Views
Registered: ‎07-14-2015

@olupj  Yes. It is marked as VHDL-2008. Otherwise it will throw a bunch of errors

 

@drjohnsmith after adding some dummy generic to the pixel_to_matrix component, no errors were present. But this is not the case with the original design. 

I thought it may be because the tool cannot go deep enough to figure out the 'length. But I simplified the design to use a 3D array. 

 

Tags (3)
0 Kudos
Highlighted
Scholar
Scholar
267 Views
Registered: ‎08-01-2012

Note: this is an opinion post.

While this does appear to be a tool  bug (have you tried in Vivado 2020.1), for myself I have come to the conclusion that sometimes, using uncosntrained ports without generics can be more of an annoyance than a help. For example, unconstrained outputs must always be connected to something to allow sizing, even if you really want them unconnected, so you end up needing a dummy signal to allow it to compile. A generic can avoid this.

Additionally, if you do something like this:

entity dff is
  port map ( 
    clk  : in  std_logic;
    d    : in  std_logic_vector;
    q    : out std_logic_vector
  )
end entity;

architecture a of dff is
begin
  process(clk)
  begin
    if rising_edge(clk)
      q <= d;
    end if;
  end process;
end architecture;

Then a size missmatch between Q and D is not picked up until runtime because it does not see the size missmatch until it actually tries to assign D to Q. If a generic was included, then the error would be picked up at elaboratio when it maps the ports.

You also, cannot do something like this because of static rules:

d_inst : entity work.dff 
port map (
  d => to_slv(some_record_signal)
  ...

Here, if there was a generic, the conversion is allowed because the size of D is already known. The work around for the above is to have a correctly sized SLV signal already. But with a generic, you can simply do this:

d_inst : entity work.generic_dff 
generic map (
  W => to_slv(some_record_signal)'length
port map (
  d => to_slv(some_record_signal)
  ...

and no extra dummy signal is needed.

Highlighted
Adventurer
Adventurer
263 Views
Registered: ‎07-14-2015

@richardhead 

Thanks for your reply.

Personally, I like constrained arrays. There are many benefits in using a constrained array. Using an unconstrained array may save a little bit of typing while coding. But I agree that it is an annoyance. I am purely doing this because it's kind of unofficial coding rule. 

Another big advantage of having a constrained array is that I can stimulate and synthesis a stand-alone component without having it to be instantiated a dummy top or testbench.  Also using "open" for an unused output (I miss those). 

Anyway, this issue gives me a reason to use constrained arrays :). But I just wonder how it creates an issue and it's really weird that issue disappears if I connect a dummy generic without using it. (attached).

 

PS: I had to downgrade to 2019.1 due to some Vendor IP support. 

0 Kudos