從前，硬件和軟件工程師大多生活在自己的世界里。硬件團隊設計了芯片，調試了從鑄造廠返回的第一批樣本，讓軟件團隊測試他們的代碼。隨著虛擬平臺和其他可執(zhí)行模型變得越來越普遍，軟件團隊可以在芯片制造之前開始，有時甚至在嵌入式開發(fā)過程的早期。日程安排有更多的重疊，但團隊之間的互動仍然有限。

采用嵌入式處理器的片上系統(SoC)設計的興起給硬件和軟件的開發(fā)方式帶來了巨大的變化。由于處理器控制著SoC的大部分功能，驗證團隊通常會模擬在這些處理器上運行的代碼。由于RTL仿真速度較慢，業(yè)界已經看到仿真和FPGA原型的使用大幅增加?，F代驗證技術，包括Accellera內部正在開發(fā)的便攜式刺激標準，跨越了多個驗證平臺。

編寫驗證期間在嵌入式處理器上運行的代碼是一個關鍵挑戰(zhàn)。嵌入式程序員經常加入硬件驗證團隊來執(zhí)行這項任務。這種組織變革的一個結果是嵌入式軟件和硬件團隊之間更早、更強的互動。SoC中出現的通用CPU、卸載引擎和其他可編程內核越多，嵌入式軟件團隊的參與就越多。他們與設計和驗證工程師一起開發(fā)SoC。

嵌入式開發(fā)程序員在模擬之外仍然密切參與;他們在硬件平臺或實際芯片上的測試通?？雌饋砼c模擬測試平臺代碼非常不同。應該對測試進行調整，以利用每個平臺的獨特特征。例如，慢速模擬支持持續(xù)檢查結果的短測試，而silicon最適合長測試和累積結果。這種調整可以防止代碼下載時間或結果上傳時間影響處理器的驚人速度。

當然，最終SoC必須運行生產軟件，因此通常會努力盡快運行該軟件。這可能早在虛擬平臺和RTL仿真時就發(fā)生了，并且在仿真或FPGA原型制作期間很常見?？梢浦驳募罴夹g可以為所有的驗證和確認平臺生成嵌入式測試用例，并且在生產軟件運行之前有效地發(fā)現硬件缺陷。調試失敗的測試用例比操作系統或應用程序中的掛起更容易。

雖然對于許多嵌入式開發(fā)工程師來說，硬件和軟件開發(fā)可能仍然是獨立的學科，但他們的團隊比以往任何時候都更加緊密地合作。對早期生產軟件驗證的需求、面向SoC驗證和確認的軟件驅動測試以及跨驗證平臺的可移植性都在推動同一方向的發(fā)展。現有標準(如UVM)可能會有相應的發(fā)展，新標準(包括便攜式刺激)也會有相應的發(fā)展。