前些日子，因实验室的项目需要（不知如何将软件的逻辑转化成硬件逻辑），特请来院里一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.前期详细设计准备越充分，后边犯错越少；越后边犯错，代价越大。与软件开发同理。
