如果您要開發(fā)自己的調(diào)試工具，那么，這會很難。您可以估算數(shù)據(jù)采集模塊和中心控制器之間的傳播延時，然后，對數(shù)據(jù)流進行后處理，使其對齊。但是，這一方法難以解決時鐘域交叉的非確定性延時問題。您可以分配一路主時鐘，使用它對您采集的數(shù)據(jù)進行時間戳處理，但是，這需要很大的電路開銷。泰克等提供的商用解決方案同時使用了硬核IP和軟件算法，在底層自動完成所有這些工作。通過這些算法，可以在一個與時間相關(guān)的視圖中看到SoC不同時鐘域和不同物理位置上的事件，通常會發(fā)現(xiàn)意外的系統(tǒng)行為。

　　即使是自動完成，仍然會有變化。如果把在系統(tǒng)中不同部分同時發(fā)生的小事件作為觸發(fā)器，只定義這類事件——例如，ADC輸出等于0，而一個CPU內(nèi)核進入某一中斷服務(wù)例程，那么會出現(xiàn)什么情況？如果事件不僅僅涉及到不同的地方，而且還有不同的抽象級——例如，串行端口的接收眼圖閉上后，出現(xiàn)了堆棧上溢，又會怎樣呢？Quinton把這類跨域分配事件觸發(fā)描述為系統(tǒng)觸發(fā)的“圣杯”。正如這一隱喻所示，很難找到合適的解決方案。但是，采集了足夠的數(shù)據(jù)，經(jīng)過認(rèn)真思考，構(gòu)建能夠采集這類復(fù)雜事件的本地觸發(fā)器，通常能夠?qū)崿F(xiàn)這些解決方案。

　　從芯片到系統(tǒng)

　　我們詳細(xì)討論了芯片級調(diào)試功能，它比簡單的CPU調(diào)試內(nèi)核有很大的進步。對于開發(fā)自己的SoC的系統(tǒng)設(shè)計人員，這些數(shù)據(jù)非常有用。但是，其他人會怎樣，誰會使用他人的芯片設(shè)計？這里的很多理念仍然能發(fā)揮作用。

　　其中最首要的是重視提前做好規(guī)劃：確定用戶及其使用環(huán)境，制定測試策略，回答這些用戶可能提出的問題，規(guī)劃數(shù)據(jù)采集來支持這一策略。最大的不同是，芯片設(shè)計人員會提出這些問題，然后，在他們的SoC中開發(fā)結(jié)構(gòu)。系統(tǒng)設(shè)計人員也會提出問題，然后，通過SoC供應(yīng)商所提供的工具以及他們的支持來解答問題。

　　相應(yīng)的，系統(tǒng)設(shè)計團隊至少會向他們的SoC供應(yīng)商提出三類很難的問題。第一，芯片供應(yīng)商會提供調(diào)試工作臺——例如，Tektronix或者ARM主軟件包，來控制SoC的調(diào)試硬件嗎？主軟件包能夠很好的適應(yīng)您現(xiàn)有的系統(tǒng)調(diào)試環(huán)境嗎？

　　第二，硬件實際接觸SoC中的哪一點？您只獲得了一個CPU內(nèi)核的觸發(fā)/跟蹤功能，或者芯片提供CPU、加速器、總線和外設(shè)控制器的擴展采集，跟蹤以及交叉觸發(fā)功能嗎？第三，調(diào)試子系統(tǒng)會提供哪些方法來觀察系統(tǒng)中其他芯片和器件的狀態(tài)？

　　這些問題的答案會定義系統(tǒng)團隊連接哪類外部測量設(shè)備工作臺，在哪些工作臺上能夠?qū)崿F(xiàn)他們的系統(tǒng)調(diào)試計劃。在這么多的系統(tǒng)工程中，關(guān)鍵是盡早開始對調(diào)試進行規(guī)劃——在工程的體系結(jié)構(gòu)設(shè)計階段。沒有足夠的數(shù)據(jù)呈現(xiàn)，就開始調(diào)試基于SoC的系統(tǒng)，這種場景很快就會很難維持下去。