Polynomial Evaluation

Take a step back. Before you start, think about how the circuit would look when created. Then go back and write the code.

The multiplier entity you have created will causes a massive bias by just removing the 16 LSBs. Did you intend to do this? and did you intend to floor your results (rather than round to nearest?)

--- Quote Start ---

Take a step back. Before you start, think about how the circuit would look when created. Then go back and write the code.

The multiplier entity you have created will causes a massive bias by just removing the 16 LSBs. Did you intend to do this? and did you intend to floor your results (rather than round to nearest?)

--- Quote End ---

Dear Tricky,

I have a 16 bit DAC so I'm forced to remove the 16 LSBs.

Now I have created 7 multiplier with seven DFF with a generic delay. So that with the multipliers I can evaluate x^7, x^6, x^5...x^0 and, before the final sum (forgetting for now about the coefficients), I compensate the delays introduced by the multipliers with the DFFs.

In particular I think that x should be delayed 6 cycles in respect to x^7=((((x*x)*x)*x)*x)*x)*x, x^2 5 cycles and so on.

I have noticed that if I sum 8 signal of 16 bit at a time, I need a 24 bit output signal. By the way in VHDL seems that also the summing signals must be 24 bit. Now that I have 8 - 16 bit signals, there is a simple way on promoting them to 24 bit or I must create 8 new 24 bit signal and assignin them the 16 bit ones ?

Thank you for your time.

actually, summing 8 16 bit signals, you should only need a 19 bit result.

How are you doing the summing? signed/unsigned type do not do any bit extension for you, you have to handle it yourself.

It is difficult to understand what you mean without seeing any code.

But I worry that with your current method of removing of just removing the 16 LSBs, you wont be summing the results correctly. x^3 is going to be 48 bits wide, with x^2 32 bits. It would be wrong just to sum the 16 MSBs.

Dear Tricky,

Yes, you are right, I need a 19 bit result. My fault.

This is the code I'm implementing:

LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.numeric_std.all;
ENTITY my_poly_test IS
	PORT( in1 : IN SIGNED (15 DOWNTO 0);
				clk,clr : IN std_logic;
			 result : OUT SIGNED (15 DOWNTO 0));
END ENTITY my_poly_test;
ARCHITECTURE logic OF my_poly_test IS
	SIGNAL x2 : SIGNED (15 DOWNTO 0);
	SIGNAL x3 : SIGNED (15 DOWNTO 0);
	SIGNAL x4 : SIGNED (15 DOWNTO 0);
	SIGNAL x5 : SIGNED (15 DOWNTO 0);
	SIGNAL x6 : SIGNED (15 DOWNTO 0);
	SIGNAL x7 : SIGNED (15 DOWNTO 0);
	SIGNAL x_d : STD_LOGIC_VECTOR(15 DOWNTO 0);
	SIGNAL x2_d : STD_LOGIC_VECTOR(15 DOWNTO 0);
	SIGNAL x3_d : STD_LOGIC_VECTOR (15 DOWNTO 0);
	SIGNAL x4_d : STD_LOGIC_VECTOR (15 DOWNTO 0);
	SIGNAL x5_d : STD_LOGIC_VECTOR (15 DOWNTO 0);
	SIGNAL x6_d : STD_LOGIC_VECTOR (15 DOWNTO 0);
	SIGNAL x7_d : STD_LOGIC_VECTOR(15 DOWNTO 0);
	SIGNAL sum : STD_LOGIC_VECTOR(18 DOWNTO 0);
	
	COMPONENT my_signed_multiplier IS
		PORT( in1, in2 : IN signed (15 DOWNTO 0);
			   clk,clr : IN std_logic;
			   result : OUT signed(15 DOWNTO 0));
	END COMPONENT;
	
	COMPONENT my_generic_dff_aclr IS
	GENERIC (delay : INTEGER :=4);
	PORT( d : IN STD_LOGIC_VECTOR(15 DOWNTO 0);
			clk , clr : IN STD_LOGIC;
			q: OUT STD_LOGIC_VECTOR(15 DOWNTO 0));
	END COMPONENT;
	
	COMPONENT my_signed_adder IS
	PORT( in1,in2 : IN SIGNED (15 DOWNTO 0);
				clk,clr : IN std_logic;
			 result : OUT SIGNED (15 DOWNTO 0));
	END COMPONENT;
			  
	BEGIN
		M1 : my_signed_multiplier PORT MAP (in1,in1,clk,clr,x2);
		M2 : my_signed_multiplier PORT MAP (in1,x2,clk,clr,x3);
		M3 : my_signed_multiplier PORT MAP (in1,x3,clk,clr,x4);
		M4 : my_signed_multiplier PORT MAP (in1,x4,clk,clr,x5);
		M5 : my_signed_multiplier PORT MAP (in1,x5,clk,clr,x6);
		M6 : my_signed_multiplier PORT MAP (in1,x6,clk,clr,x7);
		DFF1: my_generic_dff_aclr GENERIC MAP(1) PORT MAP (std_logic_vector(x6),clk,clr,x6_d);
		DFF2: my_generic_dff_aclr GENERIC MAP(2) PORT MAP (std_logic_vector(x5),clk,clr,x5_d);
		DFF3: my_generic_dff_aclr GENERIC MAP(3) PORT MAP (std_logic_vector(x4),clk,clr,x4_d);
		DFF4: my_generic_dff_aclr GENERIC MAP(4) PORT MAP (std_logic_vector(x3),clk,clr,x3_d);
		DFF5: my_generic_dff_aclr GENERIC MAP(5) PORT MAP (std_logic_vector(x2),clk,clr,x2_d);
		DFF6: my_generic_dff_aclr GENERIC MAP(6) PORT MAP (std_logic_vector(x),clk,clr,x_d);
	PROCESS(clk,clr)
	BEGIN
		IF clr ='1' THEN
		x2<=(OTHERS => '0');
		x3<=(OTHERS => '0');
		x4<=(OTHERS => '0');
		x5<=(OTHERS => '0');
		x6<=(OTHERS => '0');
		x7<=(OTHERS => '0');
		x2_d<=(OTHERS => '0');
		x3_d<=(OTHERS => '0');
		x4_d<=(OTHERS => '0');
		x5_d<=(OTHERS => '0');
		x6_d<=(OTHERS => '0');
		x7_d<=(OTHERS => '0');
		ELSIF rising_edge(clk) THEN
			sum<=1+signed(x2_d)+signed(x3_d)+signed(x4_d)+signed(x5_d)+signed(x6_d)+signed(x7_d);
			result<=sum(19 DOWNTO 3);
		END IF;	
	END PROCESS;
END ARCHITECTURE logic;

Every time I take a mutiplication I take only the 16 MSbs. So at the final sum each signal is exactly 16 bits wide.

Thank you for help.

Right, there are going to be many problems here:

1. your "My_signed_multiplier" delay is 2 clocks. So using in1 directly to each multiplier stage is going to mean x3 is going to be x2 multiplied by the value of in1 2 clocks after the value of in1 to create x2. So you need to create pipelined versions of the input to allign it properly.

2. You cannot clear x2-7 and xN_d in the other process - they are assigned from the components. This will cause multiple driver errors

3. You've got the magnitude problem I mentioned in my previous post when doing the sum. What you're doing is like this:

lets imagin we have X^3 + X^2 + X + 7, and say X is 25. THe answer should be 16282.

SO, according to your code:

X^3 = 15625, lets lose the 2 LSBs (as we're doing 2 mults), we get 156.

X^2 = 625, lets lose the LSB, we get 62

so 156 + 62 + 25 + 7 = 250. Nothing like the actual answer, even if we dropped the 2 LSBs from the correct answer.

You need to pay attention to bit allignment when you do the multiplies and adds. Otherwise you end up adding values together that are orders of magnitude apart.

4. Other coding stype point: Please use named association in entity instantiation rather than positional

(plus if you want to, ditch the component declarations all together and go with direct instantiation):

eg:

my_ent_inst : entity work.my_ent
generic map (
  some_generic => 1,
  --etc
)
port map (
  portA => input1,
  portB => input2,
  --etc
)

It is less prone to the annoying errors you get with positional.

(And for direct instantiation, the compiler checks the entity matches the instantiation, rather than the component declaration, so you get an instant error if there is a missmatch, rather than waiting for the error to pop out during elaboration which can be several minutes later).

Dear Tricky,

I have also noticed that i had to pipeline the input to multiply it correctly.

I think I have understood your point about multiplying and summing, I will follow your suggestions and then recode. When finished I will be back.

Thank you very much.

--- Quote Start ---

Dear Tricky,

I have also noticed that i had to pipeline the input to multiply it correctly.

I think I have understood your point about multiplying and summing, I will follow your suggestions and then recode. When finished I will be back.

Thank you very much.

--- Quote End ---

IF your application permits you can discard 16 LSBs from each result and so keeping all mults same width. Then at final result add 16 leading zeros. The accuracy suffers but it is still very very close.

Dear Tricky,

So if I have understood correctly I have to scale before summing like

x^7+x^6/(2^1)+x^5/(2^2)+x^4/(2^3)+x^5/(2^4)+...+x/(2^6)+1/(2^7)

Finally upgrade each xi signal to 19 bit signal ( eg: ("000") & x ) and take the 16 MSbs.

I cant't understand when you say:

4. other coding stype point: please use named association in entity instantiation rather than positional

(plus if you want to, ditch the component declarations all together and go with direct instantiation)

Could you be more specific about it?

Thank you so much !

Have a nice day.

You wouldnt do divides like that, you can just append leading or trailing 0s, like Kaz suggested before the add, as long as you remember how many you need. The highest power is going to have the biggest effect though, and the smaller powers hardly any difference on the output (unless they are scaled by a large number).

I cant really be more specific about my coding point - I gave you a coded example. In VHDL, you do not need component declarations unless your code comes from another source (say Verilog, AHDL or a generated netlist). The entity declaration already has the ports listed, so by using direct instantiation you tell the compiler where to get the entity from. The problem with using a component is that you essentially have 2 copies of the same thing (component and entity) which means you need to maintain it in two places. If there is a missmatch, the compiler always assumes the component is correct, and then when it tries to map the component to the entity (which can be many minutes later during a compile) there is a missmatch and it will error. Using direct instatiation means it does the check right at the start.

--direct instantiation
some_entity_inst : entity some_library.some_entity
generic map (
....
)
port map (
...
);

--- Quote Start ---

IF your application permits you can discard 16 LSBs from each result and so keeping all mults same width. Then at final result add 16 leading zeros. The accuracy suffers but it is still very very close.

--- Quote End ---

Thank you kaz !

Do you suggest to add the 16 leading zeros at each multiplication and then taking always the 16 MSbs ?

If don't I suppose that if I want to evaluate x^7 I would have to add much more than 16 bit or I am wrong ?