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

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

　　從芯片到系統(tǒng)

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

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

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

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

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