FPGA设计代码整洁之道2 如类、方法、函数

mdy吴伟杰

《极限编程实施》作者Ron  Jeffries 仔细研究了贝克的简单代码规则，并依其重要顺序分别列为：

＆  能通过所有测试

＆  没有重复代码

＆  体现系统中的全部涉及理念

＆  包括尽量少的实体，比如类、方法、函数等

能通过所有测试这一点，后文中在架构设计方面详细说明，这里我们还是借助一个小的例子说明“没有重复代码”的一些技巧。

曾经有一次我将多份不同的程序代码用A4纸打印出来，平摊到我的床上对照时，还在上小学的女儿在旁边说道：爸比，你每天就是看这几只毛毛虫爬来爬去吗？always、if、else，begin，对了，还有end，大概就是这几只。小孩子幼稚的话语引得我哈哈大笑，当我回头看向这些代码时，突然记起一位大师说过的话：大部分程序都是由极为相似的元素构成。诚哉斯言！同时，由于这种相似性，许多程序中出现了重复的代码。我们来看一下下面这组代码：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

assign data0 = {1'b1,din0,1'b0}; assign data1 = {1'b1,din1,1'b0}; assign data2 = {1'b1,din2,1'b0}; always  @(posedge clk or negedge rst_n)begin     if(rst_n==1'b0)begin         dout <= 0 ;     end     else if(sel0)begin         dout <= data0[9-cnt2];     end     else if(sel1)begin         dout <= data1[9-cnt2];     end     else begin         dout <= data2[9-cnt2];     end end

这是一个串口发送程序的代码，所实现的功能是发送0、1、2三个数据。很明显，在第2到第4行中，相当于程序中同样的事情做了三遍。第10到第19行也是选了三次，这就属于重复的代码。随着信号越来越多，就需要不断的四个、五个……N个。程序越来越累赘。

同一段代码的反复出现，“唯一性”的边界变得模糊，也容易出现混乱。或者说，作者的想法没有得到最佳的实现。在本例中假设通过搜索引擎输入“？”就会得到相似的？个结果。还记得前文中提到的“做简单的事”吗，这时我们应该思考是代码自身赘余还是对象功能是否太多。如果是前者，应该从有效命名等去改善它；如果是后者，那就“把复杂的事情简单化”，采取某种手段重构它，使功能可以清晰的被说明以及被实现。

如上面的代码，正确的思路和做法应该是什么呢？我们来看下面这份代码。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

always  @(*)begin     if(sel0)         din_sel = din0 ;     else if(sel1)         din_sel = din1 ;     else         din_sel = din2 ; end assign data = {1'b1,din_sel,1'b0}; always  @(posedge clk or negedge rst_n)begin     if(rst_n==1'b0)begin         dout <= 0 ;     end     else begin         dout <= data[9-cnt2];     end end

首先先把din0，1，2选出来，如果se10的情况下，那么din-se1等于din0；否则，在se11的情况下，那么din-se1等于din1；否则，din-se1等于din2；

接下来我们再来补充0和1；

接着选择时序。dout的变化为XXXXXX，到此代码完成。

通过比较不难看出，第二份代码中，无论是补0补1，还是dout送出，都只做一次，一行代码只做一件事且做好这件事，让编程语言看起来像是专为解决这个问题而存在的。

还有一点，在本节的两个例子中，验证时前一份代码要依次验证，送出的信号din0，din，din2……din N，这个过程中任何一点出现错误都非常麻烦；而第二份代码仅需要验证它们之间的逻辑关系正确即可。

需要注意的是，本节是以一个非常小的信号输出代码为例。越是大型的、复杂的代码，这两种方法之间的效率和质量差距越大。下一节《信号命名和定义应该明确》