LabVIEW系統設計軟件對數字開(kāi)發(fā)的影響

　　概覽

　　長(cháng)期以來(lái)的預測趨勢揭示了整個(gè)系統設計流程中的設計和測試趨于統一，這兩個(gè)先前獨立的功能將被集成在一起。集成功能的明顯優(yōu)勢在于縮短了投入市場(chǎng)的時(shí)間并獲得更好的整體質(zhì)量，而這些優(yōu)勢都歸功于在創(chuàng )建設計的同時(shí)集成了測試定義和實(shí)現。在系統設計過(guò)程中，從仿真到實(shí)現以及最終系統部署，都可以對這些早期測試平臺進(jìn)行重用。

　　為了真正實(shí)現設計和測試統一，尤其對于類(lèi)似RF通信等復雜功能，需要在測試和實(shí)現的設計生命周期的所有階段都能夠有效執行所選的系統設計軟件和語(yǔ)言。在這之前，用于系統仿真或設計與用于系統實(shí)現的工具及技術(shù)存在很大不同。此外用于設計和實(shí)現的工具和語(yǔ)言通常不同于測試中使用的工具。這將導致不同功能團隊使用不同的工具，將增加交流的復雜程度并降低設計和測試中可重用代碼的流動(dòng)性。這些因素都是實(shí)現設計和測試統一的主要障礙，因此理想的系統設計軟件需要提供單一語(yǔ)言用于仿真、實(shí)現和測試，并在所有設計階段和功能間最大化代碼重用。

　　減少限制的傳統方法

　　通常能夠跨越設計過(guò)程各個(gè)階段和功能的工具都嘗試著(zhù)減少每個(gè)階段和功能之間的限制，而不是創(chuàng )建可跨越所有階段和功能的單一環(huán)境和語(yǔ)言。例如，在新興的RF通信標準開(kāi)發(fā)中，通信系統設計專(zhuān)家可能會(huì )使用純數學(xué)算法對通信流進(jìn)行建模和仿真。為了測試模型，設計人員可能會(huì )創(chuàng )建自定義的測試平臺或者重用合規套件對工業(yè)標準協(xié)議進(jìn)行測試。

　　當設計功能達到要求時(shí)，從設計到實(shí)現的傳統轉換方法會(huì )將算法交給其它組，并通過(guò)手動(dòng)方式將數學(xué)算法轉換為程序實(shí)現，通常將根據實(shí)現的執行要求使用ANSI C或HDL語(yǔ)言?！　?/p>

圖1. "V"框圖通常用于說(shuō)明設計、實(shí)現和測試的理想流程。將通用系統設計語(yǔ)言用于
跨越整個(gè)"V"流程可以最大化技能和算法重用，同時(shí)可以最小化轉換錯誤和查找修正周期數。

　　此外需要轉換測試平臺本身，該轉換步驟需要具有不同技能的其他組實(shí)現，并且任何轉換中丟失的部分都可能導致新缺陷或測試覆蓋度降低。即使初始轉換階段可能不夠復雜，但該問(wèn)題會(huì )隨著(zhù)重新定義設計或發(fā)現程序實(shí)現缺陷等變得更加復雜。設計算法和程序實(shí)現的分離將導致“查找并修復”開(kāi)發(fā)周期變慢。

　　為了緩解部分問(wèn)題，一些工具可提供自動(dòng)代碼生成步驟以便幫助仿真至ANSI C或HDL的轉換。雖然該過(guò)程有利于將算法設計遷移至處理器或現場(chǎng)可編程門(mén)陣列(FPGA)，但仍需要由熟悉ANSI C或HDL的開(kāi)發(fā)人員進(jìn)行部署和調試設計?？赡懿粫?huì )存在完美的原始設計，而自動(dòng)代碼生成也會(huì )存在缺陷。

　　LabVIEW所提供的單工具方法

　　替代方法將利用到NI LabVIEW系統設計軟件，通信設計人員可以使用LabVIEW對通信流進(jìn)行建模，然后實(shí)現測試平臺。當滿(mǎn)足設計和測試要求后，系統設計人員僅需將設計算法的終端直接重新設定為處理器或FPGA以用于具體程序實(shí)現。從最初的實(shí)驗性設計到最終程序實(shí)現，系統設計人員可以使用相同的環(huán)境、算法以及調試和測試方法。該方式可以最大化技能和算法重用，同時(shí)最小化轉換錯誤和查找修正周期數。

　　既然在設計、實(shí)現和測試中重用相同算法而無(wú)需獨立的代碼生成步驟可提供各種優(yōu)勢，那么為什么其他系統設計軟件不直接使用重用的方法?這主要是由于一些歷史原因導致了該情況的出現。大多數系統設計軟件最初用于仿真空間，并且該仿真已為系統行為的時(shí)域驗證進(jìn)行優(yōu)化，然后向程序實(shí)現方向發(fā)展。LabVIEW核心為系統實(shí)現，并朝設計和仿真方向發(fā)展。其編程語(yǔ)言、環(huán)境以及更重要的IP/算法模塊是為了在處理器和FPGA上以實(shí)時(shí)速率進(jìn)行編譯和執行而設計的。