前些日子，因實驗室的項目需要（不知如何將軟件的邏輯轉化成硬件邏輯），特請來院裏一FPGA專家進行輔導，去旁聽記下筆記若干並整理成文檔，以免日後忘卻。又，雖現在不做FPGA，但介紹的開發經驗、思想方法等很難得，暫時記下，以備後用。
1. wire與reg之外的數據類型不要在verilog代碼中出現。
2. assign(組合邏輯)與always之外的語句不要在verilog代碼中出現。
3. 一個module最好一個always，再加若干assign，這樣便於控制。
4. verilog中無函數調用及函數傳遞，都轉化成input、output接口。
5. 不建議使用for循環，因爲看不到其電路是什麼樣子。
For可以用狀態機控制，狀態機可以打圈，定義一個計數器，做爲循環的索引。
動態次數的循環，用一個寄存器記錄處理的次數，再加一個狀態信號判結束。
6. 寫代碼時防止生成鎖存器，那對硬件並不是個好東西。
7. 在項目需求中，如果有時序、資源、速度等方面的要求，就要仔細設計；否則，就省事一點，只需累加邏輯，做出功能則可。
8. 用test bench等工具針對大的工程進行仿真，quarters用來做小的，比如計數器。
9. 站在一定的高度看：FPGA內部的問題都是小問題，而接口往往較難，比如異步時鐘問題，可能與內部不一致。
10. 在寫代碼的時候就不要寫不可綜合的語句，這樣前仿出來之後，後仿就並不是很費事，只是有資源的約束而已。
寫代碼之前，先找個規範看看，比如華爲的，然後規規矩矩的寫，後仿真就會快的多。
11. 不同模塊的調用以時序來控制，且確保一個模塊是以整體的形式進行工作（即並行）。換言之，用狀態信號控制不同模塊的啓用，配合狀態機加以控制。
12. 一定要採用同步處理，即在同一時鐘下，所有數據要受信號控制。
13. 如何控制時延？
用時鐘控制時延，且延遲必須以時鐘爲單位進行控制，因爲硬件系統是基於節拍爲單位的，所以在代碼中不允許出現具體多少ns的形式。
14. 軟件代碼向硬件轉化的若干指導原則：
(1).首先要簡化數據結構，比如將鏈表簡化成數組，即用順序存儲的形式來組織數據結構。這個並不難，但卻大大方便了硬件的實現與操作。
(2).邏輯電路的特點是呈現階段性、鬆耦合性，在設計時用自頂向下的方式，分析整體功能、再逐步抽象成小的模塊。
(3).在設計時一定要考慮時序的要求，規劃並畫出時序邏輯電路，確定第1個時鐘做什麼、第2個時鐘做什麼，到最後哪個時鐘出結果。
(4).整體、階段性以及子模塊內部等大都用狀態機來控制，很多情況下難以解決的問題，一用狀態機之後就迎刃而解了。
(5).注意C語言寫出的代碼只是驗證及保證功能及邏輯的正確性，在轉化時，寫的是硬件不是軟件。
15. 不建議把C函數與verilog模塊直接對應，一定要考慮時序、數據的依賴關係。越偏向軟件寫，效率越低；越偏向硬件寫，效率越高。
16. 將串行代碼改成並行代碼的一個方法：考查數據依賴。軟件是串行的思想，比如在一個函數中若有兩個變量，有操縱的先後之分，如果這兩個變量沒有先後的依賴，則最好將這個塊拆成兩個塊進行並行。
17. RAM分內外，內部是指FPGA內，外部的是在板子上連接的器件。如果用外部的RAM，在做板子之前可以用數組的方式模擬外部RAM。
18. 處理輸入的幾種方式：
需要什麼，送入什麼，用時序和信號進行控制；
一個時鐘送入一個，送入的先寄存下來；
也可以將總線放寬，一次傳入更多的數據。
19. 寄存器太多了怎麼辦：
首先，不要超過資源的限制；其次，可以考慮並設計成共享方式使用。
20. 建議路由存放在ram中，不要轉化成硬件邏輯。
21. FPGA設計的幾個主要思路（可能不完全，未加以考證）：
並行流水線，緩衝，FIFO，乒乓（讀A寫B，讀B寫A，用這兩組存儲器）。
22. 調專用的IP core往往比直接寫效率高，比如乘法器。
23. 如何考查資源是否可用：先虛構一個，將評估的數據都加進去，然後用ISE（比如quatuers）檢測是否夠用。
24. 得有一個人做整體規劃，制定方案，需開好幾次會才能確定下來。提前要儘可能的設計框架、畫框圖、以及相關的細節。在實現時，負責模塊的，要經常輸出文檔，並注重團隊合作，接口很重要。
25. 在紙上先畫時序，至少畫大的時序，再寫代碼，不要代碼寫成什麼時序就是什麼。找找畫時序圖的樣例（不嫌費事也可以用viso畫）。對數據流、控制流的設計最重要。
26.前期詳細設計準備越充分，後邊犯錯越少；越後邊犯錯，代價越大。與軟件開發同理。