第一章節
1：驗證主要保證從特性列表到RTL轉變的正確性，包括但不限於以下幾點：
·DUT的行爲表現是否與特性列表中要求的一致。
·DUT是否實現了所有特性列表中列出的特性。
·DUT對於異常狀況的反應是否與特性列表和設計規格說明書中的一致， 如中斷是否置起。
·DUT是否足夠穩健， 能夠從異常狀態中恢復到正常的工作模式。
2；Verilog在驗證方面最大的問題是功能模塊化、隨機化驗證上的不足，這導致更多的是直接測試用例（即direct test case，激勵是固定的，其行爲也是固定的） ，而不是隨機的測試用例（即random test case，激勵在一定範圍內是隨機的，可以在幾種行爲間選擇一種），筆者親身經歷過一個使用Verilog編寫的設計，包含有6000多個測試用例。假如使用SystemVerilog，這個數字至少可以除以10。
3；SystemC 算法需求非常複雜的，如圖形圖像處理等。那些對算法要求非常高的設計在使用Verilog編寫代碼之前，會使用C或者C++建立一個算法模型，即參考模型（reference model） ，在驗證時需要把此參考模型的輸出與DUT的輸出相比，因此需要在設計中把基於C++/C的模型集成到驗證平臺中， 用戶需要自己管理內存，指針會把所有人搞得頭大，內存泄露是所有C++用戶的噩夢。除了內存泄露的問題外，SystemC在構建異常的測試用例時顯得力不從心。
4；SystemVerilog 它具有所有面向對象語言的特性：封裝、繼承和多態，同時還爲驗證提供了一些獨有的特性，如約束（constraint） 、功能覆蓋率（functional coverage），它提供了DPI接口，可以把C/C++的函數導入SystemVerilog代碼中，SystemVerilog語言本身提供內存管理機制，它還支持系統函數$system，可以直接調用外部的可執行程序，就像在Linux的shell下直接調用一樣。用戶可以把使用C++寫成的參考模型編譯成可執行文件，使用$system函數調用。
5：方法學；
1）驗證平臺中都有哪些基本的組件， 每個組件的行爲有哪些？
2）驗證平臺中各個組件之間是如何通信的？
3）驗證中要組建很多測試用例， 這些測試用例如何建立、 組織的？
4）在建立測試用例的過程中， 哪些組件是變的， 哪些組件是不變的？
5）驗證平臺中數據流與控制流如何分離？
6）驗證平臺中的寄存器方案如何解決？
7）驗證平臺如何保證是可重用的？
方法學又不僅僅是一個庫，庫只是方法學的具體實現，如同上面的那些問題，如果能夠把它們都完整地規劃清楚，那麼這就是屬於讀者自己的驗證方法學；如果把思考結果用代碼實現，那就是一個包含了驗證方法學的庫
7；如何用UVM搭建驗證平臺：包括如何使用sequence機制、 factory機制、 callback機制、 寄存器模型（register model） 等。
如何編寫代碼才能保證可重用性：如何保證自己在這個項目寫的代碼在下一個項目中依然可以使用， 如何保證自己寫出來的東西別人能夠重用， 如何保證子系統級的代
碼在系統級別依然可以使用； 對於同一公司來說， 如何保證下一代的產品在驗證過程中能最大程度使用前一代產品的代碼