我是简练编码的狂热爱好者。一般说来(但不是绝对)越短的代码就越好。在一页有良好的空格和格式的代码中,能够看到的代码越多,才越容易理解设计或是验证代码的意图。<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
在我看来,任何额外的begin-end总会消耗掉一行或是两行的代码空间,最近流行的"// end-always"风格(即在end后面加注释)给代码增加了不必要的混乱,这样的话在找到和辨识出重要的细节前需要更多的浏览。
我根据孩子们同名猜谜书将这个称之为"Where's Waldo"法则。即使Waldo穿着鲜红色的和white stripped的衬衫,但是当他被足够多的混乱包围着的时候,Waldo也是极难被找到的。和Waldo难以被找到相类似,当简单的RTL代码被不合适的空格和格式以及给描述很清楚的代码加上的愚蠢注释,代码的错误就很难被注意到。
我经常给那些甚至没有经过仿真的代码修改格式和删除愚蠢的注释来修改代码中的错误。
D触发器的例子(11行代码,129个字符)- 冗长不良代码间隔的例子
always @(posedge clk or negedge rst_n)
begin
if (!rst_n)
begin
q <= 0;
end // end-if-begin
else
begin
q <= d;
end // end-else-begin
end // end-always-begin
Always块的begin-end实际上怂恿了有缺陷的RTL代码风格。如果额外的代码加在第一个begin声明后面,代码在综合的时候将会失败。
Example DFF (3 lines of code, 57 characters) - simple, concise and well-spaced:
D触发器的例子(3行代码,57个字符)- 简单明了以及良好代码间隔的例子:
always @(posedge clk or negedge rst_n)
if (!rst_n) q <= 0;
else q <= d;
注意:为了让q赋值容易被辩识,在列方向上两个赋值要对齐。
by Cliff Cummings of Sunburst Design (www.sunburst-design.com)
文章评论(0条评论)
登录后参与讨论