20110304 Debug的思維

說到Debug應該是每個RD都會遇到的事，Debug功力在不同的RD身上是有高低之分的，我本身對於線路的特性還有利用手邊可用的資料去分析問題算是頗熟練的，不過對於高手的Debug思維模式真的還需要好好學習。

昨晚收到同事寄來一個問題的分析結果，蠻神奇一個問題，因為問題A與root cause B在分析結果上是看不出關聯性的，說真的看人家分析的結果都很快，不過我把事情整個倒推回去，從Datasheet跟線路還有量測的結果來比對，真的很難去分析到A跟B的關聯性。

而我今天花很多時間去想這個已經有答案的問題，找尋手邊的所有相關的資料去想為什麼"能找出"B就是造成A的原因呢? 如果這種類似的問題再遇到一次，是否能直接由目前的知識與資訊去解開呢? 所以我就去請教分析出原因的傑奇大人，為什麼他會想到要看這些地方…


我請教完傑奇大人之後，統整出來這次他分析的流程大概是這樣:

1. 利用手邊還有之前已經分析過的現象，量測結果做基礎，去比對Data sheet中的sequence, timing與condiction是否哪個環節有問題? 這邊是大量的資訊來源，因為遇到問題時一定是先follow標準的驗證流程去找關鍵點電壓跟信號位準來判斷問題。

2. 將第一點所取得的大量資訊做收斂，從幾個比較大的可能性去驗證，再量測 –> 得到新的資訊，再回到第一點去比對。

3. 如果有些地方因為IC的datasheet寫不清楚，不知道內部的動作，就把有可能懷疑的地方(也許是電壓，電流或是參考點)，改變條件再Try一次。這步最繁雜(因為問題出在HW的話，很多都要跳線處理)，因為要大量實驗，這次也就是這個步驟找到B跟A的關聯。這邊應該就是高手跟熟手的差距了!

4. 因為已經找到B的電壓不對，會導致問題A發生。所以將手邊所有資料去找B看是否有哪些特別要注意的，果然就找到有一兩句話特別強調B在某些情況下是當別的condiction的。


看人家解出來分析的結果都很容易，畢竟那個最困難的地方絕對不會在分析的報告中出現，而我真正要學習的就是遇到棘手的問題時，高手是怎麼去Debug的思考模式，畢竟這才是下次如果我遇到這類神奇無關聯性的問題，能解開的它的釣竿。