Why my chip go into testmode so easily！

Status
Not open for further replies.
O

orinoflow

Newbie level 5
Joined
Nov 20, 2010
Messages
8
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Visit site
Activity points
1,377
hello every body!
I met a strange thing on my chip. It goes into testmode very easily. By my design this is not impossible！
The testmode state is controlled by the following RTL code. It is very clear to go into testmode, we must add a complex wave form on FCLK and DATA, and any erro on the wave form will get the statemachine back to IDLE state.
FCLK and DATA is connected to the PAD's input pin directly.
But now on the test, I find that the chip often go into testmode, and I am sure the two PADs related to FCLK and DATA can't get a legal wave form that can led it into testmode.
If I stuck FCLK to gnd, It will no go into testmode.


Who knows somthing about this ?
thanks! 


Code dot - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84

library ieee;
use     ieee.Std_Logic_1164.all;
use         ieee.std_logic_unsigned.all;
use         ieee.std_logic_unsigned."+";
use         ieee.std_logic_unsigned.conv_integer;
use         ieee.std_logic_arith.conv_unsigned;
 
entity IntoTestmode is
  port(
    notReset                : in  std_logic;
    FCLK                      : in  std_logic;
    DATA                    : in  std_logic;
        TESTMODE                        : out   std_logic
      );
end IntoTestmode;
 
architecture RTL of IntoTestmode is
 
    type t_Serial is (e_SYNC0,  e_SYNC1,  e_SYNC2,  e_SYNC3,  e_SYNC4,  e_SYNC5,  e_SYNC6,  e_SYNC7,  e_SYNC8,  e_SYNC9,
                                        e_SYNC10, e_SYNC11, e_SYNC12, e_SYNC13, e_SYNC14, e_SYNC15,
                                        e_SYNC16, e_SYNC17, e_SYNC18, e_SYNC19,
                                        e_SYNC20, e_SYNC21, e_SYNC22, e_SYNC23, e_SYNC24, e_SYNC25, e_SYNC26, e_SYNC27, e_SYNC28, e_SYNC29,
                      e_SYNC30, e_IDLE);
    signal  Serial : t_Serial;
 
begin
 
    p_Main: process(FCLK, notReset)
    begin
        if notReset = '0' then
            TESTMODE <= '0';
            Serial              <= e_IDLE;
        elsif (FCLK'event and FCLK = '1') then
        
            --  '1''0''1''1''0''1''1''1'  --LSB--> 0xED
            --  '0''1''0''0''1''1''0''1'  --LSB--> 0xB2
            --  '0''1''0''0''1''0''1''1'  --LSB--> 0xD2
            --  '0''1''1''1''0''0''1''X'  --LSB--> 0xCE/0x4E
            --SYNC : 0xEDB2D24E : CHECK   0xEDB2D2CE : BRUN
            case Serial is
            
                when e_IDLE     => if DATA = '1' then   Serial <= e_SYNC0; else Serial <= e_IDLE;     end if;
                when e_SYNC0  => if DATA = '0' then Serial <= e_SYNC1; else Serial <= e_IDLE;     end if;
                when e_SYNC1  => if DATA = '1' then Serial <= e_SYNC2; else Serial <= e_IDLE;     end if;
                when e_SYNC2  => if DATA = '1' then Serial <= e_SYNC3; else Serial <= e_IDLE;     end if;
                when e_SYNC3  => if DATA = '0' then Serial <= e_SYNC4; else Serial <= e_IDLE;     end if;
                when e_SYNC4  => if DATA = '1' then Serial <= e_SYNC5; else Serial <= e_IDLE;     end if;
                when e_SYNC5  => if DATA = '1' then Serial <= e_SYNC6; else Serial <= e_IDLE;     end if;
                when e_SYNC6  => if DATA = '1' then Serial <= e_SYNC7; else Serial <= e_IDLE;     end if;
                
                when e_SYNC7  => if DATA = '0' then Serial <= e_SYNC8; else Serial <= e_IDLE;     end if;
                when e_SYNC8  => if DATA = '1' then Serial <= e_SYNC9; else Serial <= e_IDLE;     end if;
                when e_SYNC9  => if DATA = '0' then Serial <= e_SYNC10; else Serial <= e_IDLE;  end if;
                when e_SYNC10 => if DATA = '0' then Serial <= e_SYNC11; else Serial <= e_IDLE;  end if;
                when e_SYNC11 => if DATA = '1' then Serial <= e_SYNC12; else Serial <= e_IDLE;  end if;
                when e_SYNC12 => if DATA = '1' then Serial <= e_SYNC13; else Serial <= e_IDLE;  end if;
                when e_SYNC13 => if DATA = '0' then Serial <= e_SYNC14; else Serial <= e_IDLE;  end if;
                when e_SYNC14 => if DATA = '1' then Serial <= e_SYNC15; else Serial <= e_IDLE;  end if;
                
                when e_SYNC15 => if DATA = '0' then Serial <= e_SYNC16; else Serial <= e_IDLE;  end if;
                when e_SYNC16 => if DATA = '1' then Serial <= e_SYNC17; else Serial <= e_IDLE;  end if;
                when e_SYNC17 => if DATA = '0' then Serial <= e_SYNC18; else Serial <= e_IDLE;  end if;
                when e_SYNC18 => if DATA = '0' then Serial <= e_SYNC19; else Serial <= e_IDLE;  end if;
                when e_SYNC19 => if DATA = '1' then Serial <= e_SYNC20; else Serial <= e_IDLE;  end if;
                when e_SYNC20 => if DATA = '0' then Serial <= e_SYNC21; else Serial <= e_IDLE;  end if;
                when e_SYNC21 => if DATA = '1' then Serial <= e_SYNC22; else Serial <= e_IDLE;  end if;
                when e_SYNC22 => if DATA = '1' then Serial <= e_SYNC23; else Serial <= e_IDLE;  end if;
                
                when e_SYNC23 => if DATA = '0' then Serial <= e_SYNC24; else Serial <= e_IDLE;  end if;
                when e_SYNC24 => if DATA = '1' then Serial <= e_SYNC25; else Serial <= e_IDLE;  end if;
                when e_SYNC25 => if DATA = '1' then Serial <= e_SYNC26; else Serial <= e_IDLE;  end if;
                when e_SYNC26 => if DATA = '1' then Serial <= e_SYNC27; else Serial <= e_IDLE;  end if;
                when e_SYNC27 => if DATA = '0' then Serial <= e_SYNC28; else Serial <= e_IDLE;  end if;
                when e_SYNC28 => if DATA = '0' then Serial <= e_SYNC29; else Serial <= e_IDLE;  end if;
                when e_SYNC29 => if DATA = '1' then Serial <= e_SYNC30;                         end if;
                when e_SYNC30 => TESTMODE <= '1';
        
        end case;
 
        end if;
 
    end process p_Main;
 
end RTL;
 
Last edited by a moderator:

Have you checked the shape and the voltage of your signals ?
Have you tried with a logic analyzer (or a scope may do the job) to trigger on the output "testmode", then check which input has led into this state ?
Of course, ensure that the frequency of FCLK is not above the one given to synthesis tool !
Perhaps you driving circuit has a problem : adding a pulldown resistor (several kOhm) on data may help to debug. Do not forget to never let MOS input floating !

A good practice is to divide your state machine into (at least) two process, using a next_state signal for example.
Thus you ensure that the state change is synchronous. In your process, you both affect and test the state.
A better way could be :

Code: 
process(clk)
if reset='0' then ... end if ;
if clk'event and clk='1' then
    next_state <= State
end if
end process

And in you p_Main process, you just change (sample) :
Code: 
                when e_SYNC0  => if DATA = '0' then next_sate <= e_SYNC1; else next_state <= e_IDLE;     end if;

Let me know !
 

thank you gag2000 ，I did some test and now have some finds.

Because this is a Asic，not FPGA， so I can't probe testmode. But I use a scope see the FCLK and DATA on the chip's pads. There did have some glitches on the two pads. Because the pads is not schmitt pads, so I think the circuit falls into testmode because of metastablity.



Glitches on the pads is about 500mv ( chip works on 3V). It seemd that 500mv lower than VCC is impossible led metastablity occur. But I think the Glitches on the inside side of pads is much bigger. I verified this point by using software probe the pad's input. It does have many wrong state when a powerful waveform added to the pad beside it.

So the most possible question is the PAD’s design have some problems（The pad is not a standard cell supplied by fundry，but designed by us），We will check it。

thank you!
 

Hi,

How do you generate these signals (FCLK and DATA) ? If I assume that they are generated by external equipment, so the glitch may be eliminated quite easily, with external DFF for examples.
You can try to delay the data with respect to the clock, thus ensuring that clock edge is synchronized with stable voltage of data.

What process are you using for your chip ?
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…