08-06-2020 07:33 AM
I'm receiving the following error with regards to unconstrained ports in my design using Vivado 2018.2.
"[Synth 8-549] port width mismatch for port 'INPUT_0': port width = 18, actual width = 15 ..."
What I eventually noticed is that the above port width is the same width as where I'm using the same module elsewhere in the design, and changing it is mirrored in the error. It seems Vivado is trying to enforce the same signal constraint on two different parts of the hierarchy.
I understand that UG901 recommends not to use unconstrained ports, but it's something my team decided to do for ease of maintenance. Additionally, the port is a custom type for holding complex sfixed pairs. It has happened on more than one occasion where we've realized we're pushing what our version of Vivado can handle, but moving to a newer version isn't realistic right now.
Has anyone attempted the same thing and found a work around? Or is there some combination of synthesis options that will make Vivado less confused in this situation?
08-06-2020 08:00 AM
08-06-2020 10:11 AM - edited 08-06-2020 10:27 AM
I can't share source files, but I can give some example code. In the course of typing it up it seemed like this isn't particularly helpful, but I can at least show how things are implemented. The data type synthesizes without issue in other modules. I can see about providing a better example, given some time.
-- type and component definitions are in a separate package. type iq_index is (i, q); type complex_sfixed is array(iq_index range <>) of sfixed; component complex_multiply port( reset : in std_logic; clock : in std_logic; enable : in std_logic; input_valid : in std_logic; input_0 : in complex_sfixed; input_1 : in complex_sfixed; output_valid : out std_logic; output : out complex_sfixed ); end component;
signal input_0, input_1 : complex_sfixed(i to q)(data_msb downto data_lsb); signal complex_mult_output : complex_sfixed(i to q)(2*(data_msb + 1) downto 2*data_lsb);
inst_complex_mult : complex_multiply -- Error points here, and references input_0, input_1, and output. port map( reset => reset, clock => clock, enable => enable, input_valid => input_valid, input_0 => input_0, input_1 => input_1, output_valid => OPEN, output => complex_mult_output );
08-07-2020 12:24 AM
Without an example that exhibits the behaviour, it is difficult to comment on your exact problem. Vivado 2018.2 had a lot of problems with VHDL2008 (which your example shows with use of unconstrained array type). Vivado 2019.2 has much improved 2008 support, so I would highly recommend you migrate to this version at least.
You also using a lesser used indexing method, by using a non-integer type as an array index. While Im not saying this is a problem of itself, it does invite the possibility errors because you're straying from the "norm", and Vivado has a lot of history of problems when you stray from the norm (its taken 10 years to get decent VHDL 2008 support, with some bugs lingering for many versions).
The "usual" version would be to define constant integers for i and q, and create the type based on these:
constant IP_INDEX_I : natural := 0; constant IP_INDEX_Q : natural := 1; type complex_sfixed is array(IP_INDEX_I to IP_INDEX_Q) of sfixed;
If you can post a small example that exhibits the problem, maybe we can be more specific.
08-13-2020 12:55 PM
I'm working to put together an example design that shows the problem I'm having, and will have that ready in the near future.
Want to also add that I attempted to synthesize using the webpack version of 2020.1 and saw an entirely different issue. The hierarchy view showed missing source files, despite the source files appearing under the included sources in the libraries tab. "Abnormal program termination (EXCEPTION_ACCESS_VIOLATION)" also showed in the log when attempting to run synthesis.