對系統(tǒng)硬件或軟件所做的修改可能并不會立即影響系統(tǒng)行為，對不是馬上要執(zhí)行的軟件所做的代碼修改在它運行之前不會改變系統(tǒng)行為。例如，雖然對一個1,000個周期后才被調用的軟件例程做了修改，但系統(tǒng)行為在前面1,000個周期內是不變的。

設計師需要能夠從代碼或設計修改開始起作用的那點開始恢復仿真。在上述例子中，這意味著設計師應該在第1,000個周期時作出代碼修改并重新啟動仿真，不用再次運行前面1,000個周期。

當設計已經(jīng)改變、新的塊可能已經(jīng)增加到系統(tǒng)模型中時，問題就比較難解決了。設計師沒有這個新塊過去保存的數(shù)據(jù)用于恢復。另外，設計師可能有許多IP塊由于各種理由(如編譯的，受保護的IP塊)而表現(xiàn)為黑盒子，這些塊將無法參與保存/恢復操作。

假如設計師可以對設計作出修改，相信寄存器值沒有變化，并能重新啟動修改后的仿真，那么設計師如何能根據(jù)硬件或軟件變化而知道系統(tǒng)行為將要改變的確切點呢？不知道這點的話，設計師將要么重新啟動得太早而浪費不需要的仿真周期，要么重新啟動得太晚而錯過一些變化了的行為。

另外，如果系統(tǒng)行為很早就改變了，但只是發(fā)生在設計的很小部分又會怎樣呢？即使系統(tǒng)的小部分受到影響，系統(tǒng)的絕大部分模塊在上千個周期內也不會受到改變的影響。

理想的解決方案是只在系統(tǒng)行為即將從上一次運行基礎上發(fā)生改變時的那個點重新啟動系統(tǒng)中的每個主要模塊。然而這樣做顯然行不通，因為只要任何一個模塊開始執(zhí)行，它就要求與其他模塊發(fā)生交互，就需要來自這些模塊的信號，并發(fā)送信號給這些模塊。

圖：在少量修改后運行的仿真經(jīng)常會完全重復前次仿真過程已經(jīng)完成的工作。

解決這個問題的方法之一是考慮在I/O邊界處保存每個塊的行為，使得捕捉到的I/O信號可用于復用，而不用實際計算每個模塊的仿真行為。復用保存在I/O邊界的信號可以節(jié)省重新計算該模塊行為所需的計算工作，減少工作量，進而提升系統(tǒng)性能。

當設計運行到修改開始影響特定模塊的仿真時，設計師可以再次開始仿真，并停止使用保存的信號值。

設計師如何知道仿真何時已經(jīng)改變了呢？除了復用保存的模塊輸出值外，設計師還保存了輸入信號。在每個周期內，設計師可以將實際的輸入信號值與保存的輸入信號值進行比較。當保存值與實際值匹配時，設計師就能知道輸出結果與上次運行結果是相同的。

這種方法的效果取決于假設執(zhí)行信號和檢查點讀取所需的時間小于執(zhí)行實際仿真所需時間，從而加速仿真的能力。顯然，具有內部活動和少量I/O引腳的大模塊的速度提升幅度要比具有許多I/O信號的小模塊顯著得多。在前一種情況下，保存和恢復I/O信號的成本要低于仿真模塊行為所需付出的代價。在后一種情況中，在某些點保存和恢復信號數(shù)據(jù)的成本將超過仿真模塊的代價。

有助于減少必須保存的數(shù)據(jù)量的一種方法是只在時鐘周期上采樣I/O信號。通用使用周期級(cycle-level)接口，設計師可以確保他或她只需要一個周期采樣或分析信號值一次，而不是每個周期內以隨機次數(shù)進行采樣。因為大多數(shù)總線接口是周期精確型接口，因此這種方法通常沒有什么問題。

實現(xiàn)這種系統(tǒng)所需要的功能要求設計師：

. 監(jiān)視和捕捉特定模塊的輸入和輸出。

. 將接口轉換成在周期邊界上工作。

. 以指定間隔查明所有寄存器值。

. 從保存文件中恢復出信號用作輸出值。

. 將保存的輸入值與實際值進行比較。

. 發(fā)現(xiàn)失配時，加載最近的檢查值，只允許該模塊仿真到當前時間，然后從該點開始繼續(xù)正常的仿真。

Carbon設計系統(tǒng)公司在周期級模型編譯器的“重放”特性中實現(xiàn)了上述功能。該模型編譯器接收寄存器傳輸級代碼，創(chuàng)建周期級編譯后的模型，并提供周期級模塊接口。其余功能則在編譯期間于基本的I/O模型邊界創(chuàng)建的部分包裝器(wrapper)中實現(xiàn)。