摘要：長期以來的預測趨勢揭示了整個系統設計流程中的設計和測試趨于統一，這兩個先前獨立的功能將被集成在一起。在系統設計過程中，從仿真到實現以及zui終系統部署，都可以對這些早期測試平臺進行重用。
　　
　　概覽
　　
　　長期以來的預測趨勢揭示了整個系統設計流程中的設計和測試趨于統一，這兩個先前獨立的功能將被集成在一起。集成功能的明顯優勢在于縮短了投入市場的時間并獲得更好的整體質量，而這些優勢都歸功于在創建設計的同時集成了測試定義和實現。在系統設計過程中，從仿真到實現以及zui終系統部署，都可以對這些早期測試平臺進行重用。
　　
　　為了真正實現設計和測試統一，尤其對于類似RF通信等復雜功能，需要在測試和實現的設計生命周期的所有階段都能夠有效執行所選的系統設計軟件和語言。在這之前，用于系統仿真或設計與用于系統實現的工具及技術存在很大不同。此外用于設計和實現的工具和語言通常不同于測試中使用的工具。這將導致不同功能團隊使用不同的工具，將增加交流的復雜程度并降低設計和測試中可重用代碼的流動性。這些因素都是實現設計和測試統一的主要障礙，因此理想的系統設計軟件需要提供單一語言用于仿真、實現和測試，并在所有設計階段和功能間zui大化代碼重用。
　　
　　減少限制的傳統方法
　　
　　通常能夠跨越設計過程各個階段和功能的工具都嘗試著減少每個階段和功能之間的限制，而不是創建可跨越所有階段和功能的單一環境和語言。例如，在新興的RF通信標準開發中，通信系統設計專家可能會使用純數學算法對通信流進行建模和仿真。為了測試模型，設計人員可能會創建自定義的測試平臺或者重用合規套件對工業標準協議進行測試。
　　
　　當設計功能達到要求時，從設計到實現的傳統轉換方法會將算法交給其它組，并通過手動方式將數學算法轉換為程序實現，通常將根據實現的執行要求使用ANSIC或HDL語言。　　
　　圖1."V"框圖通常用于說明設計、實現和測試的理想流程。將通用系統設計語言用于跨越整個"V"流程可以zui大化技能和算法重用，同時可以zui小化轉換錯誤和查找修正周期數。
　　
　　此外需要轉換測試平臺本身，該轉換步驟需要具有不同技能的其他組實現，并且任何轉換中丟失的部分都可能導致新缺陷或測試覆蓋度降低。即使初始轉換階段可能不夠復雜，但該問題會隨著重新定義設計或發現程序實現缺陷等變得更加復雜。設計算法和程序實現的分離將導致"查找并修復"開發周期變慢。
　　
　　為了緩解部分問題，一些工具可提供自動代碼生成步驟以便幫助仿真至ANSIC或HDL的轉換。雖然該過程有利于將算法設計遷移至處理器或現場可編程門陣列（FPGA），但仍需要由熟悉ANSIC或HDL的開發人員進行部署和調試設計。可能不會存在的原始設計，而自動代碼生成也會存在缺陷。
　　
　　LabVIEW所提供的單工具方法
　　
　　替代方法將利用到NILabVIEW系統設計軟件，通信設計人員可以使用LabVIEW對通信流進行建模，然后實現測試平臺。當滿足設計和測試要求后，系統設計人員僅需將設計算法的終端直接重新設定為處理器或FPGA以用于具體程序實現。從zui初的實驗性設計到zui終程序實現，系統設計人員可以使用相同的環境、算法以及調試和測試方法。該方式可以zui大化技能和算法重用，同時zui小化轉換錯誤和查找修正周期數。
　　
　　既然在設計、實現和測試中重用相同算法而無需獨立的代碼生成步驟可提供各種優勢，那么為什么其他系統設計軟件不直接使用重用的方法？這主要是由于一些歷史原因導致了該情況的出現。大多數系統設計軟件zui初用于仿真空間，并且該仿真已為系統行為的時域驗證進行優化，然后向程序實現方向發展。LabVIEW核心為系統實現，并朝設計和仿真方向發展。其編程語言、環境以及更重要的IP/算法模塊是為了在處理器和FPGA上以實時速率進行編譯和執行而設計的。
　　
　　除了實現算法重用，LabVIEW的程序實現傳統很大程度上對部分仿真-時間活動進行了加速。例如，LabVIEW可將臺式機算法完整編譯為處理器的機器代碼。對于純功能DSP類型算法，系統設計人員將以相對于連續時域仿真方法的更快速度對算法進行實現和調試。與用于終端FPGA的設計仿真相比，該優勢尤其明顯。LabVIEW可支持位及周期精度仿真的預期形式。在特定情況下功能測試通常能滿足需求，但LabVIEW可將速度提高多個數量級，主要原因為功能代碼已為本地功能執行進行了*編譯和優化，而不再僅僅是"仿真"。相對于較慢的仿真算法，在仿真中重用快速的實現算法更具實際用途，因此與其他系統設計軟件相比，LabVIEW優勢更為明顯。
　　
　　LabVIEW系統設計和RF通信設計
　　
　　在RF的設計和測試趨于統一范例中，相對于普遍統一的趨勢，通信設計將導致部分*的復雜性。zui主要情況為，當測試RF接收器時必須創建一個發送器，而測試發送器也必須創建一個接收器。大多數時候該測試的信號和測試特性必須超出設計本身規范。此外RF通信方法和標準的變更頻率十分迅速，這也對測試本身的靈活性和速度提出了要求。因此用于RF的理想測試儀器必須允許快速重用發送器和接收器數字信號處理（DSP）算法，并且具備高性能和靈活性。
　　
　　該類測試的傳統方法將會創建特定功能的儀器，以用于測量和測試特定的通信類型。如需*覆蓋設計和測試，不僅需要在設計流程中考慮測試流程、測試平臺和附加因素，而且在理想狀態下設計和測試需要直接使用實際硬件和信號而不僅是仿真。在LabVIEW和NIPXIe-5644R矢量信號收發器范例中，當在臺式機中定義通信流的DSP基本構件并執行預期功能后，設計人員可以將算法終端從臺式機設計環境更改為運行FPGA的矢量信號收發器。　　
　　圖2.NIPXIe-5644R矢量信號收發器的架構可允許在主機或設備固件中仿真和部署用戶可編輯的DSP塊。同時也可以對其他輸入/輸出以及內存接口進行修改以作為算法設計的補充。
　　
　　該遷移的主要因素以及從算法設計到zui終部署（無論是設計本身或測試）的主要障礙是能否正確集成實際定時，更重要的是，硬件I/O和信號校準。對于設計和測試功能，DSP算法設計人員通常不同于實現包含I/O集成在內的設備固件的團隊。通過矢量信號收發器和LabVIEWRIO可編程設備，NI將提供可靈活編程的RF硬件平臺，該平臺將包含高度優化的IP塊。該程序塊可管理與信號校準集成的高速A/D和D/A的常規復雜度，以及至主機處理器和高速板載內存的DMA數據流。該矢量信號收發器中的IP代表了三個主要特性。首先可以在臺式機中仿真功能以便用于算法設計。其次源代碼可用于參考或修改。如之前所述，zui后可支持無縫遷移至實際實時執行系統。
　　
　　集成設計、開發和部署
　　
　　為了真正實現從算法到部署的緊密系統設計流程，必須具備完整的軟件/硬件視角。軟件必須包含正確的定時、I/O和DSP算法IP。該IP必須能支持仿真執行，而且需要快速執行功能調試并支持快速設計周期，并且zui終能將測試和設計代碼從臺式機環境遷移至可編程的部署硬件。
　　
　　用戶開發的算法和測試均屬于重要知識產權（IP），而任何系統設計工具的主要任務在于zui大化開發效率，允許用戶在原設計和zui終實現存在較小差別時對相同IP進行重用。僅當系統設計軟件zui初為了程序實現采用了開放和可重用的構建模塊，并且該基本構建模塊可*匹配用于迭代式設計過程的可重配置硬件時，才可能實現上述方式。而結合LabVIEW系統設計軟件和支持LabVIEWRIO的矢量信號收發器可以達到這一目標。