最近收拾書架，翻出一張多年以前的ASIC項目開發流程圖，一起回顧一下。典型的瀑布式開發流程：

　　以算法設計為主導

　　算法C代碼手工轉換為RTL

　　RTL與算法C代碼生成的測試向量對比進行驗證

　　依賴FPGA做大量實時、現場測試

　　適合通信信號處理，音視頻處理產品

　　1. 算法預研

　　確定了產品方向之后，算法工程師開始進行調研。

　　要學習研究行業內最新的研究成果、論文，提出創造性的方法來獲得最好的性能。要使用真實的測試數據和仿真結果進行評估。最終交付為算法描述的C語言源碼。

　　算法調研結束后需要進行審核(review)：確定算法性能，確定系統架構設計，確認是否可以正式立項。審核過程需要算法設計、RTL設計、軟件、硬件系統、市場、管理層共同參與。

　　正式立項時，需要提供功能spec，以及算法C代碼功能仿真環境。與此同時，硬件組需要根據項目需求開始搭建硬件FPGA測試平臺。

　　2. 算法優化

　　接下來進行算法的優化，主要考慮以下幾個方面：

　　算法復雜度

　　算法運算量

　　變量精度

　　算法設計以及狀態機控制要具有自恢復能力

　　算法代碼要足夠stable，對于各種濾波器系數和變量要有一定的噪聲容忍度。

　　算法最終確定需要通過審核：算法架構，算法功能仿真，算法定點化和性能驗證。

　　3. 面向ASIC的C代碼實現

　　在此階段，算法C仿真代碼改變為模塊結構代碼，分解為若干ASIC功能模塊，代碼的接口與RTL接口接近：

　　容易實現

　　高效率

　　節省邏輯

　　重用現有模塊

　　對帶有反饋的模塊中增加仿真延時

　　在接口增加仿真延時

　　最終的C代碼中：

　　主函數只包含連接關系和子模塊

　　所有子模塊以各自的時鐘速率調用

　　接口采用cycle based timing

　　需要準備以下review和文檔：

　　ASIC模塊和接口設計指導

　　性能驗證報告

　　接口變量的時序圖和精度描述

　　4. C到RTL的實現

　　RTL設計工程師完成從C代碼到verilog的實現。算法工程師負責產生相應的測試向量，包括子模塊測試和系統聯調測試。要使用各種典型的測試場景數據，以及一些子模塊級別的隨機測試數據。

　　根據RTL設計以及綜合結果，可以獲得整個系統的時序信息，gate count和die size預估。

　　5. FPGA on-board test

　　由于RTL仿真的速度較慢，可以借助FPGA來進行測試加速。硬件工程師準備FPGA平臺，FPGA工程師進行RTL到FPGA的代碼移植，軟件工程師協助相關測試軟件的開發與使用。

　　在FPGA上可以做到與RTL仿真一樣的效果，比如從內存中提供輸入，并抓取輸出結果，與算法C產生的數據進行比對。需要測試盡可能多的測試用例。

　　6. FPGA field test

　　如果項目代碼可以在FPGA上跑到與真實應用同樣的速度(full speed)，就可以用FPGA代碼直接做實時現場測試。在現場測試的任何問題，需要反饋給算法組進行分析解決。

　　7. Final Check and Review

　　現場測試通過后，需要做最后的檢查和review全部代碼，然后開始芯片后端設計。

　　站在今天(2018年)的角度看過去上述流程有存在一些問題：

　　采用算法C到Cycle C再到RTL實現的流程，迭代長，易出錯

　　RTL驗證以直接定向測試為主，缺少隨機驗證，覆蓋率不夠

　　依賴FPGA實時測試作為驗證主要手段，FPGA平臺開發需要專門的人力資源和硬件平臺，而且FPGA平臺不夠靈活，且容易出現不穩定的問題。

　　現在已經有很多新技術可以借鑒，比如

　　基于High level synthesis，縮短開發周期

　　采用各種驗證方法學，提高驗證覆蓋率

　　使用專用的硬件加速器平臺

　　最后，以上開發流程簡單，投資少，對于算法(大牛)主導的創業型公司，或者以IP開發為主的小型團隊，還是可以使用的。