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

從芯片到系統

我們詳細討論了芯片級調試功能，它比簡單的CPU調試內核有很大的進步。對于開發自己的SoC的系統設計人員，這些數據非常有用。但是，其他人會怎樣，誰會使用他人的芯片設計?這里的很多理念仍然能發揮作用。

其中最首要的是重視提前做好規劃：確定用戶及其使用環境，制定測試策略，回答這些用戶可能提出的問題，規劃數據采集來支持這一策略。最大的不同是，芯片設計人員會提出這些問題，然后，在他們的SoC中開發結構。系統設計人員也會提出問題，然后，通過SoC供應商所提供的工具以及他們的支持來解答問題。

相應的，系統設計團隊至少會向他們的SoC供應商提出三類很難的問題。第一，芯片供應商會提供調試工作臺——例如，Tektronix或者ARM主軟件包，來控制SoC的調試硬件嗎?主軟件包能夠很好的適應您現有的系統調試環境嗎?

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

這些問題的答案會定義系統團隊連接哪類外部測量設備工作臺，在哪些工作臺上能夠實現他們的系統調試計劃。在這么多的系統工程中，關鍵是盡早開始對調試進行規劃——在工程的體系結構設計階段。沒有足夠的數據呈現，就開始調試基于SoC的系統，這種場景很快就會很難維持下去。