[SOLVED] cannot have aggregate operand - vhdl

[rakeshk.r]

HI, I have a compilation error: "Type conversion (to SIGNED) can not have aggregate operand." My guess is that there might be an issue with conversion from real type to signed. Any help to resolve this issue is greatly appreciated. Thank you.

LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.numeric_std.all;
USE ieee.math_real.all;

ENTITY test_lut IS
-- Declarations
Generic (K : integer := 4);
Port( x : in unsigned(3 downto 0);
       y : out signed (26 downto 0));

ARCHITECTURE logic OF test_lut IS
  
  function my_exp(i : integer) return signed is
  begin
         return signed(exp(-(real(i)/16.0**K)), 27);  -- error is shown in this line.
   end function;
BEGIN
  y <=  my_exp(0) when x = "0000" else
        my_exp(1) when x = "0001" else
        my_exp(2) when x = "0010" else
        my_exp(3) when x = "0011" else
        my_exp(4) when x = "0100" else
        my_exp(5) when x = "0101" else
        my_exp(6) when x = "0110" else
        my_exp(7) when x = "0111" else
        my_exp(8) when x = "1000" else
        my_exp(9) when x = "1001" else
        my_exp(10) when x = "1010" else
        my_exp(11) when x = "1011" else
        my_exp(12) when x = "1100" else
        my_exp(13) when x = "1101" else
        my_exp(14) when x = "1110" else
        my_exp(15) when x = "1111" ;

END ARCHITECTURE logic;
END test_lut ;

 

[ads-ee]

Even if that line of code worked, it would produce a huge amount of combinational hardware with lots of levels of logic. Both division and exponentiation are very logic intensive operations and should be done using a pipeline unless you don't care if your result is computed as slow as a snail.

VHDL is not a software language it's a hardware description language. Stuff like this you can get away with in software because it's all done sequentially anyways (SW mantra: who cares how many instructions and how much memory it takes, we'll just specify better computer hardware (unless you're doing embedded sw, then you will care)).

 

[rakeshk.r]

This fixed the error: to_signed(natural(scale_factor*(exp(-(real(i)/16.0**K)))), 18) , where scale_factor would be 256.0 for '8' fractional bits in 'x'.
But I have a question, when you say "huge amount of combinational hardware with lots of levels of logic" , is that due to 'exp' function that I have used ? If so, then by storing the expoenential values in LUT, would you agree it will reduce this huge amount combinational hardware ?

 

[FvM]

Even if that line of code worked, it would produce a huge amount of combinational hardware with lots of levels of logic. Both division and exponentiation are very logic intensive operations and should be done using a pipeline unless you don't care if your result is computed as slow as a snail.

Don't think so. The code (with syntax errors fixed) compiles to a 16x27 bit look-up table. All calculations are performed at compile time.

 

[rakeshk.r]

@FvM So u mean it is ok to use the above way of coding to implement exponential computations ?

 

[FvM]

Basically yes. The parameters in the original design seem to give constant output because my_exp() is more or less saturated. But reasonable parameter scaling can be checked with a pocket calculator. You also changed the number of output bits which must be reflected by y width.

 

[rakeshk.r]

@FvM Like you said i get constant zeros. I believe I have to scale. But not sure how. Should I do that by adding/removing zeros at LSB/MSB of the divisor (16.0**K). Here I have made K=0 and I am not multiplying scale_factor like i mentioned above as i am taking 'exp' of integer bits.

 

[FvM]

I can't tell because I don't exactly understand the intended calculation.