[Also posted to comp.lang.vhdl by mistake, sorry about that]
Hi,
I'm trying to debug a Cyclone design which writes values taken from a lookup table to the address inputs of a crosspoint analog switch. The problem is that everything looks OK in the Quartus simulator, but when I test the design on the target hardware it seems to be pulling the wrong values out of the LUT. I have tried enabling SignalTap and probing the output pins during the write operation, SignalTap reports correct operation but the outputs, as measured on a real logic analyser, are wrong.
E.g. for CHANNEL=1, eeprom_en='0', path=0 I should get 0,0,0,0,B,A,
3,2, I actually get 0,0,0,0,9,8,3,2
The lookup table is implemented thus:
library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all;
entity xpswitch is generic(PLL_CLK_FREQ : integer; CHANNEL : integer); port( pll_clk : in std_logic; sys_rst : in std_logic; path_index : in integer range 0 to 7; eeprom_en : in std_logic; go : in std_logic; busy : out std_logic; AX : out std_logic_vector(3 downto 0); AY : out std_logic_vector(2 downto 0); CS : out std_logic; DAT : buffer std_logic; RST : out std_logic; STRB : out std_logic ); end xpswitch;
architecture rtl of xpswitch is
type t_ax_lut is array(0 to 7) of std_logic_vector(3 downto
0); signal ax_lut : t_ax_lut; signal ay_count : integer range 0 to 7;
begin
p_lut : process(eeprom_en, path_index) begin case CHANNEL is when 1 =>
if(eeprom_en = '1') then case path_index is when 0 => ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut if(eeprom_en = '1') then case path_index is when 0 => ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut if(eeprom_en = '1') then case path_index is when 0 => ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut ax_lut end case; end process;
The output will depend on CHANNEL, eeprom_en, path_index but also ay_count. The first three are inputs, but I don't see where ay_count is ever assigned a value. Is this signal being set correctly? I can't explain your symptoms by assuming this signal is not correct, but it is the only issue I see that might wrong. I also can't explain your symptoms by assuming any of the inputs are wrong, but fixed. Could an input be changing as the measurements are made?
I assume that ay_count free runs through a sequence and the data you list are the same four signals sampled in time? If so, you only have one output of the four that is wrong. Can you use SignalTap to look at all the intermediate points and narrow down where it is failing? I prefer to route the signals out to pins and use the logic analyzer or scope to look at stuff. I have to use a tool a lot to trust it (meaning to trust that I am using it right).
Fixed it now - it turned out that the code was doing exactly what I intended, it was the external IC whose specs I hadn't read properly.
Regarding SignalTap, I usually prefer to have a few spare pins routed to test points but this is a very dense board, no space for luxuries like test points! I have always found the Altera JTAG tools to be dependable in the past, anyone have any different experiences?
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.