1

I'm designing a customizeable interpolation filter and I'm looking for the best way to pass the coefficients (rather supporting points) to the filter. Below you see the current implementation.

package lin_interpol_filter_unsigned_pack is
        type supp_point_vector is array (integer range <>) of integer;
end package;

--! Use std libraries.
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.lin_interpol_filter_unsigned_pack.all;
entity lin_interpol_filter_unsigned is

    generic ( 
        --! Determines number of interpolations steps by steps = 2 ^ <interpol_steps_exp_g>
        interpol_steps_exp_g    : integer := 6;
        input_width_g           : integer := 12;
        output_width_g          : integer := 12
    );

    port (
        clk_i               : in std_logic;
        supp_points_vect_i  : in supp_point_vector (0 to 2**interpol_steps_exp_g);
        input_stream_i      : in unsigned (input_width_g downto 0);

        output_stream_o     : out unsigned (output_width_g downto 0)
    );

end;

The user would then have to pass the supporting points to the module as a constant. Now I'm worried that Vivado can't optimize the input port to the minimum bit-width, but instead uses the full (32bit?) integer range. Can I expect Vivado to minimize the bit width?

I'm not entirely happy with this approach. I would rather like the user to pass the supporting points as a generic, but the generic declaration would then be dependent on another generic (the interpol_steps_exp_g generic) which isn't allowed. Is there maybe another way to pass the supporting points conveniently?

Thank you.

SamGibson
  • 17,231
  • 5
  • 37
  • 58
Andy Ef
  • 113
  • 1
  • 10
  • what signal specifically are you worried about? I really can't follow you here. – Marcus Müller Nov 01 '18 at 10:48
  • 1
    I see it as OP wants the vector to change dynamically depending on the "constant" passed from the higher level module. Well, IMHO this constant must be defined at the compilation level so that fitter can fit, or maximum constant used (32 as OP said) to accomodate any possible values passed. – Anonymous Nov 01 '18 at 11:05
  • 1
    @Anonymous this is correct. I basically want to know if the 64 supporting points (or any other 2^n value defined by interpol_steps_exp_g) will allways consist of a 32bit wide bus, or if Vibado is able to limit the bus width to 12bit if every one of the 64 buses holds a constant value smaller than 2^12-1. – Andy Ef Nov 01 '18 at 11:23

1 Answers1

2

I basically want to know if the 64 supporting points (or any other 2^n value defined by interpol_steps_exp_g) will allways consist of a 32bit wide bus, or if Vibado is able to limit the bus width to 12bit if every one of the 64 buses holds a constant value smaller than 2^12-1.

I am not familiar with tools you use, but any modern compiler is able to optimize the design, and if it sees at the stage of compilation that higher bit are not used, it will remove related parts of registers/wires and all other supporting logic.

Look into the optimization settings of your compiler.

Finally, I think it should be correct if you define interpol_steps_exp_g's size of appropriate number of bits at the source level; if compiler will see that some instance uses inexisent indexed of the vector, it will throw the error.

Anonymous
  • 6,908
  • 1
  • 14
  • 41