驗證涉及每個階段的迭代循環：仿真、檢查結果，改變激勵或設計或調試設置，重新仿真并不斷重復。在系統調試過程中，軟硬件在多次運行之間可能會有改變，因此系統調試也變得更為復雜。

某些驗證可以被分解成多個可以并行運行的小型仿真。這種方法對許多旨在確認硬件本身的測試來說是非常有效的，但并不是所有測試都適合。像視頻流處理這類測試就很難被分解成多個較小的測試，因為這種處理的對象是整個數據流，而且每個幀都依賴于它前面的幀。

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

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

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

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

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

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

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

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

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

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

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

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

實現這種系統所需要的功能要求設計師：

. 監視和捕捉特定模塊的輸入和輸出。

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

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

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

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

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

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