10-21-2020 08:09 AM - edited 10-21-2020 08:13 AM
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': 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.
10-21-2020 10:33 AM
10-21-2020 10:37 AM
@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;
10-21-2020 11:44 AM
10-22-2020 12:01 AM - edited 10-22-2020 12:01 AM
@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.
10-22-2020 01:55 AM
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.
10-22-2020 02:05 AM
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.