不斷增加的復雜性和異質化正在衍生出一些新的方法，能夠避免在設計周期結束時出現意外。

在一個系統中，硬件的表現是否優秀取決于運行在其上的軟件。隨著系統復雜性的增加，總是軟件在拖后腿。

縮小硬件和軟件差距的方法是不斷改進軟件開發的方法。在把軟件部署運行在硬件上之前，確保軟件升級都進行了驗證和測試，并進行之前芯片制造商開發硬件時進行的同類的詳細檢查。

試圖將軟件開發過程提前并不是什么新主意。多年來，業界開發了一系列的方法解決這個問題。比如敏捷軟件開發方法，它試圖通過兩個或更多的軟件開發者同時進行同一個代碼的開發來降低錯誤。此外還包括持續集成方法，它是從另外一個角度解決這個問題的，這個方法的本質是，將代碼持續不斷地加入共享的代碼庫或開發分支中，進行頻繁的自動構建，以在早期發現和驗證問題。

Mentor嵌入式部門產品管理總監Warren Kurisu說：“越來越多的開發團隊正在使用持續集成方法作為簡化整體開發流程的手段，并避免在開發集成階段出現令人討厭的意外?；谀Ｐ偷脑O計方法通過模擬和自動代碼生成進行了大量的工作，可以支持這種方法過程。”

通過持續集成，可以在構建硬件設備的同時，構建一個單純從概念出發的數字映像。在這種方法的加持下，多個更加獨立的團隊可以同時開發，這時，更好地踐行持續集成概念就變成了各個團隊的代碼“何時”準備好集成進系統的問題。

“多團隊同時開發的方法是對持續集成模式的一種認可，這種方法使開發商能夠更早地對設計進行驗證，并允許開發人員根據數字映像模型驗證其代碼和測試系統配置。”Kurisu說。“舉一個簡單的例子吧，比如Linux進程。這種架構設計使應用程序開發人員能夠在其桌面開發系統上創建應用程序，只要它們遵守Linux編程模型，這些應用程序就可以在最終階段順利集成，甚至可以在系統部署后加載。如果系統架構師需要更嚴格的分離模型，則可以使用獨立的執行環境，如Linux容器或Docker容器。這種模式不僅適用于Linux，實時操作系統也和Linux進程很像，包括一個允許代碼分離的進程模型。”

一旦在進程或分區中運行的代碼就緒，就可以將其納入到連續集成工作流中。雖然這似乎是一個顯而易見的步驟，但它的效果很好，可以很快地將各種異構組件融合在一起。

“例如，集成了四核ARM Cortex-A53內核、Cortex-R5內核和FPGA架構，并具有可實現功能分離的多個電源層的Xilinx UltraScale + MPSoC，”Kurisu說。“可以預計的情景是多個開發團隊同時為這個SoC編寫代碼，一個團隊在應用內核上開發Linux，一個團隊在實時內核上開發安全應用程序，另一個團隊在FPGA架構上實現算法。在總體架構上，這些應用可以通過已定義的接口進行通信。一方面，這些獨立團隊自身可能會使用持續集成方法來構建在其內核上運行的代碼，另一方面，當系統所有內核上的代碼都就緒后，主要的集成工作就會開始。和上面一樣，持續集成的問題就是進行全系統集成的代碼何時準備就緒。”

基礎問題
系統的復雜性一直在穩步增長，部分原因是沒有人確定虛擬/增強現實、汽車、醫療、工業物聯網和深度學習等各種新興市場需要什么樣的芯片或功能。在這種情況下，一種常見的方法是將多個類型的處理器和功能集成在一顆芯片上，通過軟件把各個組件融合在一起，這比將所有組件放入各個分立的ASIC中更便宜。

Aldec硬件部總經理Zibi Zalewski表示：“最終配置是根據目標市場或客戶要求創建的。“子系統的可擴展性使您可以快速增加系統規模和復雜性?，F在，把一個系統從雙核擴展到四核不算什么大問題，沒有適當的工具才是真正的問題所在。此外，硬件部分不再是決定項目的主要元素，系統復雜性主要來自于軟件層。所以不單單是晶體管數量問題，還包括功能要求。”

這與系統整體質量有直接的關系，最終是衡量創建該系統的各種方法的有效性。

ARM模型技術總監Bill Neifert說：“評估質量時，挑戰在于它不僅僅涉及芯片的質量。它衡量的是整個系統，會衍生出區段問題。每個設計中都有你關心的東西，但對于汽車、工業和企業計算而言，關心對象又有所不同。一些涉及不同的硬件，另外一些則是相同硬件上的不同應用。如果您正在處理需要記錄和證據的安全相關問題，你需要關心的就是軟件過程和底層硬件。記住，你能證明到什么程度，質量就是什么水平。”

最大限度降低意外
不管選擇的方法有多好，總會有一些錯誤發生。所以，這里的目標是盡量減少項目開發最終階段的意外，記住，沒有任何一種方法能夠完全消除意外。

“當您編寫應用程序時，您真的必須在真實的目標上運行一下它，因為您可能沒有正確地分配內存，或者您可能只有只能在ARM上使用的二進制庫，而很多人卻試圖在x86上測試嵌入式系統，“Imperas Software首席執行官Simon Davidmann說。“Jenkins是一個經常被提及的開源自動化服務器，代碼可以在ARM、MIPS或瑞薩處理器上運行，不需要任何管理工作，在幾分鐘之內就可以得到一個“測試通過”的結果。你可以把Jenkins看做運行對象，你可以說，'這是我的機器。我有四臺機器可以運行測試'，其他人也可以共享Jenkins資源。它可以簡化最簡單的程序，即便你的程序只有一個只包含一個算法的文件，它也允許你構建工程并運行，當你修改了代碼，它可以自動化地充分測試并記錄。當然，您必須了解Jenkins的產品如何工作或模擬器的工作原理，但是只需要幾千美元，您就能獲得可以非常有效地進行編譯、構建、測試和驗證的系統。”

Synopsys的MetaWare產品經理Allen Watson說：“我們生產的軟件是允許人們開發軟件的工具。我們的客戶使用我們的工具編寫嵌入式軟件，但同時我們的工具本身也是軟件。雖然有一些差異，但歸根結底我們和客戶們都在編寫軟件，這是一個非常復雜的軟件。我們自己也在小組內采用持續集成方法，沒有其它方法能夠替代這種開發方式。我們有多個開發人員編寫同一個產品的軟件，但他們承擔不同的任務。通常，他們先寫自己的代碼，在本地進行一些單元測試，準備好后，就把代碼并到軟件的主線開發分支上。

但是，并不是每個人都認可這個概念。Uniquify營銷副總裁Graham Bell認為，重點應該是反復性而不是持續集成。

“持續意味著不間斷地繼續下去，而反復意味著活動之間可以暫停，”他說。“當然，嵌入式軟件的集成工作會反復經歷一系列的集成-測試 - 修改活動，直到特征漂移結束或者bug數量達到了設計簽收級別。這就是這個過程中暫停的地方。隨著設計從硅虛擬原型轉移到硬件原型，最終再轉移到消費者手中的產品，這種集成循環會一再發生。有些人可能會認為，集成工作的這些階段現在是重疊的，因為各個設計團隊需要盡早獲得有關工作設計的知識，以加速自己工作的設計簽收。如果是這種情況，那么也許我們可以說，這些同步進行的工作正在導致嵌入式軟件的持續整合。”

這不僅僅是定義上的分歧，它影響著基礎方法論。和支持反復整合的企業相比，支持持續整合的企業數量增長更多。

Austemper設計系統公司首席執行官Sanjay Pillay認為，持續集成是實現最佳上市時間的唯一途徑。“目前復雜的SoC及其開發時間表無法通過使用硬件-固件-軟件的串行開發方法來實現。工程團隊現在必須包括硬件開發人員和嵌入式軟件設計人員，而且軟件設計人員的數量往往超過硬件設計人員。他們一起開始這個項目，并在整個項目周期中并肩協作。”

但是，隨著設計中異構組件的數量不斷增多，持續集成也只是簡化開發流程的其中一個選擇。

Mentor的Kurisu說：“人們可以爭辯說，今天最先進的軟件和硬件不再需要持續集成方法。但是我認為，基于模型的設計實際上激發了持續集成方法的活力，并放大了這種方法的作用。”