在我的職業生涯中，我曾經為一些很有趣的項目做過FPGA設計，也曾挽救過許多誤入歧途的FPGA設計。我在處理這些問題設計時發現，雖然目標應用和開發團隊的成員不同，但這些設計顯然有一些通病，使設計從工程師坐下來寫第一行HDL程序代碼時，就注定了項目失敗的命運。

有鑒于此，我想有必要介紹一下我在挽救這些項目時發現的5個共同問題。這些問題是：

問題一：第一個問題是在項目開始之時沒有明確需求基線。這個問題不只與基于FPGA的開發有關，它與工程是普遍相關的。人們經常會在需求仍未成熟、還需不斷修改之時就急忙進行項目。但是如果我們沒有完全理解需求就匆匆開始開發，就可能出現初始步驟錯誤的情況，接下來的糾正則會帶來延遲和額外的成本。

太早開始項目會帶來開發風險，而這個風險需要降低。幸運的是，需求的深度和細節可以根據具體的應用進行修改。我期望為SIL4系統而不是商用系統提出許多更詳細的需求。總之，如果一開始對需求沒有達成一致意見，或沒有形成正確的需求基線，就會出現范圍蔓延問題。雖然一開始設計的架構非常合理，符合需求，但隨著需求基線的成熟，開發人員會嘗試加入新的功能，從而使架構越來越復雜。這樣用不了多久就會發生問題。

問題二：在理解需求細節之后，每個開發人員還應了解開發FPGA的計劃，因此需要制定一個計劃，定義從項目啟動到交貨要遵循的程序，確定主要開發步驟和工程審查點。

除了制訂計劃外，我們還需要以文文件的形式記錄架構和設計，確定每個主要的功能，看哪些功能是需要新開發的，哪些可以利用第三方IP或再利用現有IP(以后會越來越多)。計劃、架構和設計描述文文件可以說明工程技術團隊理清手頭的任務。我們還可以按照具體需求檢查所有的功能，確保提議的方案能夠滿足所有高層需求。

問題三：設計模塊和整個FPGA需要花費時間；但耗時更長的任務是設計驗證，以確保設計滿足需求。這種驗證不僅需要包含邏輯功能，還需要在組件所有可能的工作條件下進行。反過來說，這意味著有必要針對設計開發一個清晰的驗證策略；這不再只是寫寫程序代碼、執行一些仿真程序，然后將設計扔給硬件這么簡單了。

問題四：很多時候我們會因為過于投入某件事情而難以發現其中的問題，這正是引入工程設計審查的目的。透過審查，我們可以確保遵循良好的工程操作方法，并符合內部的開發標準。另外，它們還能幫助獨立工程師檢查設計的架構和實現，以確保提供所需的功能。如果在開發過程中不經過審查設計，可能就無法實現高質量的設計，并且可能增加下游的整合問題。

問題五：到這里你可能注意到，我提出的大多數觀點和過程是與更廣泛的工程而不是與設計編碼本身有關。開發程序代碼固然重要，但是確保我們利用第三方IP和再利用內部IP也同樣重要。

理想情況下，我們應該盡可能再利用鏈接庫中的許多現有IP塊，當不可能利用時，當然需要開發新的模塊。在創建新模塊時必須時刻牢記，這些模塊在未來的項目中應能再使用。我們應該考慮使用高層次綜合(HLS)工具來說明創建這些新模塊。因為允許我們工作在較高的抽象層，這些工具可以幫助我們更容易地拓展解決方案空間、縮短開發時間，并降低風險和成本。

上述問題是我在挽救FPGA設計時注意到的，您對誤入歧途的項目有何看法？