大神教你如何做好逻辑设计

　　我们先来看开关时延，这个时延是由器件物理特性决定的，我们没有办法去改变，所以我们只能通过改变走线方式和减少组合逻辑的方法来提高工作频率。

　　1.通过改变走线的方式减少时延。

　　以altera的器件为例，我们在quartus里面的timing closure floorplan可以看到有很多条条块块，我们可以将条条块块按行和按列分，每一个条块代表1个LAB，每个LAB里有8个或者是10个LE。它们的走线时延的关系如下：同一个LAB中(最快) < 同列或者同行 < 不同行且不同列。

　　我们通过给综合器加适当的约束(不可贪心，一般以加5%裕量较为合适，比如电路工作在100Mhz，则加约束加到105Mhz就可以了，贪心效果反而不好，且极大增加综合时间)可以将相关的逻辑在布线时尽量布的靠近一点，从而减少走线的时延。(注：约束的实现不完全是通过改进布局布线方式去提高工作频率，还有其它的改进措施)

　　2.通过减少组合逻辑的减少时延。

　　上面我们讲了可以通过加约束来提高工作频率，但是我们在做设计之初可万万不可将提高工作频率的美好愿望寄托在加约束上，我们要通过合理的设计去避免出现大的组合逻辑，从而提高电路的工作频率，这才能增强设计的可移植性，才可以使得我们的设计在移植到另一同等速度级别的芯片时还能使用。

　　我们知道，目前大部分FPGA都基于4输入LUT的，如果一个输出对应的判断条件大于四输入的话就要由多个LUT级联才能完成，这样就引入一级组合逻辑时延，我们要减少组合逻辑，无非就是要输入条件尽可能的少，，这样就可以级联的LUT更少，从而减少了组合逻辑引起的时延。

　　我们平时听说的流水就是一种通过切割大的组合逻辑(在其中插入一级或多级D触发器，从而使寄存器与寄存器之间的组合逻辑减少)来提高工作频率的方法。比如一个32位的计数器，该计数器的进位链很长，必然会降低工作频率，我们可以将其分割成4位和8位的计数，每当4位的计数器计到15后触发一次8位的计数器，这样就实现了计数器的切割，也提高了工作频率。

　　在状态机中，一般也要将大的计数器移到状态机外，因为计数器这东西一般是经常是大于4输入的，如果再和其它条件一起做为状态的跳变判据的话，必然会增加LUT的级联，从而增大组合逻辑。以一个6输入的计数器为例，我们原希望当计数器计到111100后状态跳变，现在我们将计数器放到状态机外，当计数器计到111011后产生个enable信号去触发状态跳变，这样就将组合逻辑减少了。

　　上面说的都是可以通过流水的方式切割组合逻辑的情况，但是有些情况下我们是很难去切割组合逻辑的，在这些情况下我们又该怎么做呢?

　　状态机就是这么一个例子，我们不能通过往状态译码组合逻辑中加入流水。如果我们的设计中有一个几十个状态的状态机，它的状态译码逻辑将非常之巨大，毫无疑问，这极有可能是设计中的关键路径。那我们该怎么做呢?还是老思路，减少组合逻辑。我们可以对状态的输出进行分析，对它们进行重新分类，并根据这个重新定义成一组组小状态机，通过对输入进行选择(case语句)并去触发相应的小状态机，从而实现了将大的状态机切割成小的状态机。在ATA6的规范中(硬盘的标准)，输入的命令大概有20十种，每一个命令又对应很多种状态，如果用一个大的状态机(状态套状态)去做那是不可想象的，我们可以通过case语句去对命令进行译码，并触发相应的状态机，这样做下来这一个模块的频率就可以跑得比较高了。

　　总结：提高工作频率的本质就是要减少寄存器到寄存器的时延，最有效的方法就是避免出现大的组合逻辑，也就是要尽量去满足四输入的条件，减少LUT级联的数量。我们可以通过加约束、流水、切割状态的方法提高工作频率。

　　做逻辑的难点在于系统结构设计和仿真验证

　　刚去公司的时候BOSS就和我讲，做逻辑的难点不在于RTL级代码的设计，而在于系统结构设计和仿真验证方面。目前国内对可综合的设计强调的比较多，而对系统结构设计和仿真验证方面似乎还没有什么资料，这或许也从一个侧面反映了国内目前的设计水平还比较低下吧。

　　以前在学校的时候，总是觉得将RTL级代码做好就行了，仿真验证只是形式而已，所以对HDL的行为描述方面的语法不屑一顾，对testbench也一直不愿意去学--因为觉得画波形图方便;对于系统结构设计更是一点都不懂了。

　　到了公司接触了些东西才发现完全不是这样。

　　其实在国外，花在仿真验证上的时间和人力大概是花在RTL级代码上的两倍，现在仿真验证才是百万门级芯片设计的关键路径。仿真验证的难点主要在于怎么建模才能完全和准确地去验证设计的正确性(主要是提高代码覆盖)，在这过程中，验证速度也是很重要的。

　　验证说白了也就是怎么产生足够覆盖率的激励源，然后怎么去检测错误。我个人认为，在仿真验证中，最基本就是要做到验证的自动化。这也是为什么我们要写testbench的原因。在我现在的一个设计中，每次跑仿真都要一个小时左右(这其实算小设计)。由于画波形图无法做到验证自动化，如果用通过画波形图来仿真的话，一是画波形会画死(特别是对于算法复杂的、输入呈统计分布的设计)，二是看波形图要看死，三是检错率几乎为零。

　　那么怎么做到自动化呢?我个人的水平还很有限，只能简单地谈下BFM(bus function model，总线功能模型)。

　　以做一个MAC的core为例(背板是PCI总线)，那么我们需要一个MAC_BFM和PCI_BFM及PCI_BM(PCI behavior model)。MAC_BFM的主要功能是产生以太网帧(激励源)，随机的长度和帧头，内容也是随机的,在发送的同时也将其复制一份到PCI_BM中;PCI_BFM的功能则是仿PCI总线的行为，比如被测收到了一个正确帧后会向PCI总线发送一个请求，PCI_BFM则会去响应它，并将数据收进来;PCI_BM的主要功能是将MAC_BFM发送出来的东西与PCI_BFM接收到的东西做比较，由于它具有了MAC_BFM的发送信息和PCI_BFM的接收信息，只要设计合理，它总是可以自动地、完全地去测试被测是否工作正常，从而实现自动检测。

　　华为在仿真验证方面估计在国内来说是做的比较好的，他们已建立起了比较好的验证平台，大部分与通信有关的BFM都做好了，听我朋友说，现在他们只需要将被测放在测试平台中，并配置好参数，就可以自动地检测被测功能的正确与否。

　　在功能仿真做完后，由于我们做在是FPGA的设计，在设计时已经基本保证RTL级代码在综合结果和功能仿真结果的一致性，只要综合布局布线后的静态时序报告没有违反时序约束的警告，就可以下到板子上去调试了。事实上，在华为中兴，他们做FPGA的设计时也是不做时序仿真的，因为做时序仿真很花时间，且效果也不见得比看静态时序分析报告好。

　　当然了，如果是ASIC的设计话，它们的仿真验证的工作量要大一些，在涉及到多时钟域的设计时，一般还是做后仿的。不过在做后仿之前，也一般会先用形式验证工具和通过静态时序分序报告去查看有没有违反设计要求的地方，这样做了之后，后仿的工作量可以小很多。

　　在HDL语言方面，国内语言很多人都在争论VHDL和verilog哪个好，其实我个人认为这并没有多大的意义，外面的大公司基本上都是用verilog在做RTL级的代码，所以还是建议大家尽量学verilog。在仿真方面，由于VHDL在行为级建模方面弱于verilog，用VHDL做仿真模型的很少，当然也不是说verilog就好，其实verilog在复杂的行为级建模方面的能力也是有限的，比如目前它还不支持数组。在一些复杂的算法设计中，需要高级语言做抽象才能描述出行为级模型。在国外，仿真建模很多都是用System C和E语言，用verilog的都算是很落后的了，国内华为的验证平台好像是用System C写。

　　在系统结构设计方面，由于我做的设计还不够大，还谈不上什么经验，只是觉得必须要具备一些计算机系统结构的知识才行。划分的首要依据是功能，之后是选择合适的总线结构、存储结构和处理器架构，通过系统结构划分要使各部分功能模块清晰，易于实现。这一部分我想过段时间有一点体会了再和大家分享，就先不误导大家了。