Lookup table simulation problems

Hello.

I am using Xilinx ISE Foundation 6.3i. I am trying to implement a sine lookup table (targeted at either SpartanIII or VirtexII) but I am getting a strange result when running functional simulation (testbench bellow) with Modelsim: instead of showing the first element from the array on the output after the first rising edge it shows the 12th. Everithing happens as if I had initialized the address counter with 11 instead of 0. I know I am making a basic mistake but I cannot figure out where or why.

--------------------

library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity sintab20 is Port ( i_Clk : in std_logic; i_En : in std_logic; i_Addr : in integer range 0 to 19; o_DataOut : out std_logic_vector(17 downto 0) ); end sintab20;

architecture Behavioral of sintab20 is subtype t_ROM_DATA is std_logic_vector(17 downto 0); type t_ROM_TYPE is array (natural range ) of t_ROM_DATA; constant k_SinTab20x1: t_ROM_TYPE(19 downto 0) := ( "000000000000000000", "001001111000110111", "010010110011110010", "011001111000110111", "011110011011110000", "011111111111111111", "011110011011110000", "011001111000110111", "010010110011110010", "001001111000110111", "000000000000000000", "110110000111001001", "101101001100001110", "100110000111001001", "100001100100010000", "100000000000000001", "100001100100010000", "100110000111001001", "101101001100001110", "110110000111001001" );

begin process (i_Clk) begin if rising_edge(i_Clk) then if (i_En = '1') then o_DataOut i_Clk, i_En => i_En, i_Addr => i_Addr, o_DataOut => o_DataOut );

-- *** Test Bench - User Defined Section *** i_En

Reply to
Elder Costa
Loading thread data ...

Your main test process executes in zero sim time. Consider synchronizing the process as shown below.

-- Mike Treseler

--_______________________________________

library IEEE; use IEEE.STD_LOGIC_1164.all;

entity sintab20 is port ( i_Clk : in std_logic; i_En : in std_logic; i_Addr : in integer range 0 to 19; o_DataOut : out std_logic_vector(17 downto 0) ); end sintab20;

architecture Behavioral of sintab20 is subtype t_ROM_DATA is std_logic_vector(17 downto 0);

type t_ROM_TYPE is array (natural range ) of t_ROM_DATA;

constant k_SinTab20x1 : t_ROM_TYPE(19 downto 0) := ( "000000000000000000", "001001111000110111", "010010110011110010", "011001111000110111", "011110011011110000", "011111111111111111", "011110011011110000", "011001111000110111", "010010110011110010", "001001111000110111", "000000000000000000", "110110000111001001", "101101001100001110", "100110000111001001", "100001100100010000", "100000000000000001", "100001100100010000", "100110000111001001", "101101001100001110", "110110000111001001" );

begin process (i_Clk) begin if rising_edge(i_Clk) then if (i_En = '1') then o_DataOut i_Clk_s, -- [in] i_En => i_En_s, -- [in] i_Addr => i_Addr_s, -- [in] o_DataOut => o_DataOut_s); -- [out] i_clk_s

Reply to
Mike Treseler

I don't see anything, but maybe someone else will.

It would be more usual to make the number of table entries a power of two, such that mod 360 degrees could be done by ignoring high order bits. You might see if that works better in your case.

Display both the address and table value. That should help track down the problem.

-- glen

Reply to
glen herrmannsfeldt

It turned out it *was* a basic mistake. I should have declared constant k_SinTab20x1: t_ROM_TYPE(0 to 19)

instead of

constant k_SinTab20x1: t_ROM_TYPE(19 downto 0)

So I was starting with 20th element, not 12th.

It is not possible in my application, a lock in demodulator at 2.5Msps using a 125KHz carrier.

Thanks and regards.

Reply to
Elder Costa

I figured out the problem as I pointed in another message. I will save your message though as reference as it does contain some stuff I think will help me.

Thanks and regads.

Elder.

Reply to
Elder Costa

(snip regarding sin lookup tables)

Well, it could probably be done with a phase accumulator, but if the frequencies really are fixed, yes, the 20 element table is best.

-- glen

Reply to
glen herrmannsfeldt

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.