Problems with VHDL lookup table in Quartus
in [FPGA]
|
From: Rhydian on 30 Jul 2010 06:07 On Jul 28, 5:47 pm, rickman <gnu...(a)gmail.com> wrote: > On Jul 27, 6:25 am, Rhydian <n...(a)rblack01.plus.com> wrote: > > > [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 <= > > (x"7", x"6", x"8", x"9", x"B", x"A", x"3",x"2"); > > when 1 => ax_lut <= > > (x"7", x"6", x"8", x"9", x"0", x"0", x"0",x"0"); > > when 2 => ax_lut <= > > (x"7", x"6", x"8", x"9", x"4", x"5", x"E",x"F"); > > when 3 => ax_lut <= > > (x"7", x"6", x"8", x"9", x"0", x"0", x"0",x"0"); > > when 4 => ax_lut <= > > (x"7", x"6", x"8", x"9", x"3", x"2", x"B",x"A"); [snip large LUT] > > > There are 3 instances of this code in the design, with different > > switch mappings selected by the CHANNEL parameter. They all show the > > same problem, 'B','A' is consistently replaced by '9','8'. > > > I can't resolve this discrepancy I'm seeing between what the tools are > > telling me and the behaviour when running on the target. The internal > > PLL is being used to generate a 57.6 MHz global clock; Quartus timing > > analysis shows f_max as about 85 MHz so i don't think it is a timing > > issue. I have checked the pin assignments by driving the AX outputs > > with a 4-bit counter which cycles continuously, this works correctly > > as seen on the simulator and the external logic analyser. > > > Any ideas? I have raised a support case with Altera, no response as > > yet. > > > TIA > > > R. > > 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? Yes. > 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). > > Rick 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?
From: rickman on 30 Jul 2010 11:22
On Jul 30, 6:07 am, Rhydian <n...(a)rblack01.plus.com> wrote: > On Jul 28, 5:47 pm, rickman <gnu...(a)gmail.com> wrote: > > > > > On Jul 27, 6:25 am, Rhydian <n...(a)rblack01.plus.com> wrote: > > > > [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 <= > > > (x"7", x"6", x"8", x"9", x"B", x"A", x"3",x"2"); > > > when 1 => ax_lut <= > > > (x"7", x"6", x"8", x"9", x"0", x"0", x"0",x"0"); > > > when 2 => ax_lut <= > > > (x"7", x"6", x"8", x"9", x"4", x"5", x"E",x"F"); > > > when 3 => ax_lut <= > > > (x"7", x"6", x"8", x"9", x"0", x"0", x"0",x"0"); > > > when 4 => ax_lut <= > > > (x"7", x"6", x"8", x"9", x"3", x"2", x"B",x"A"); > > [snip large LUT] > > > > > > > > There are 3 instances of this code in the design, with different > > > switch mappings selected by the CHANNEL parameter. They all show the > > > same problem, 'B','A' is consistently replaced by '9','8'. > > > > I can't resolve this discrepancy I'm seeing between what the tools are > > > telling me and the behaviour when running on the target. The internal > > > PLL is being used to generate a 57.6 MHz global clock; Quartus timing > > > analysis shows f_max as about 85 MHz so i don't think it is a timing > > > issue. I have checked the pin assignments by driving the AX outputs > > > with a 4-bit counter which cycles continuously, this works correctly > > > as seen on the simulator and the external logic analyser. > > > > Any ideas? I have raised a support case with Altera, no response as > > > yet. > > > > TIA > > > > R. > > > 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? > > Yes. > > > 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). > > > Rick > > 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? Was the other chip driving the signal low? Rick |