rtl前端实现中的两个问题：代码走读 - 可读性与综合频率的权衡

有几个疑问的地方请教一下：

1)如何进行代码走查才能高效？我现在走查代码还只能看到一些表面的编码风格之类的，如何在代码走查的时候发现功能和性能的bug哪？

2)在编写代码时，需要注意哪些东西保证综合出来的频率较高？ 如何做好代码的可读性与综合频率的trade off哪？（有时为了代码写的可读清晰，逻辑可能写的比较大）

我初步的想法：现在的rtl综合器已经能够做的较为优化，基本能够把你的代码，在等价性充分的条件下从布局布线的角度进行了优化，所以对于不是很大的逻辑以可读性为主；
在编写代码时，如果是一眼看上去就比较大的逻辑，需要考虑一下能否换成别的形式进行简化并做好代码注释。
3)国内如何上mitbbs呢？

关于1)我自己的经验是review时再仔细，能直接发现的bug也非常有限，从文档开始到code做review，对寻找架构设计中的缺陷比较有效。

绝大部分情况下可读性对性能没有半点影响
反而可读性差的设计往往会迷惑综合器造成各种问题
如果真有需要写的很奇怪才能保证性能的代码
可以加上大段的注释或者外部文档链接，也算是提高可读性

还是稍微有一点影响的吧。一个always块对应一个reg，工具优化的能力比较强；假如你为
了可读性，把若干个reg交织的在一个always块中赋值，有时候会有一些冗余逻辑。但是，
我觉得，可读性是最重要的，面积大一点小一点，在目前这种工艺条件下，又能大多少
呢。who care

如果用某种tool可以根据design自动生成RTL蕴含的assertions，review这些assertion是否会更加高效？

有点同意
感觉现在的合成工具，想Design Compiler越来越智能了
以前在RTL设计时，要避免的书写方式，现在好像都不是很重要了

re
以前就强制要求一个always快对应一个reg
除非是类似FIR的那种tap的移位寄存器，才把几个reg写到一起
其实这样写，可读性也还可以
至少思路很清晰，看到一个带时钟的always块就是一个寄存器

我一直都觉得
对于一些算法很固定的模块
完全可以用high level synthesize 的办法，完全没有必要写RTL
比如FIR，IIR，Cordic，etc
甚至，诸如ADS或者simulink的那种schematic的netlist，就可以翻译成RTL或者直接综合成gate
当然，前提条件是，那个schematic要设计得足够好
我曾经试验过写代码读入ADS的netlist，然后分析，最后自动生成RTL。
但是做了个开头，想了想，还是算了吧。我要是做出来了，我就要失业了。。。。。

我这里有个小同学
写代码，给某个寄存器赋值
喜欢自己把条件化到最简
就是直接写成
if ( a&&b||!c&&d... )
   reggg<= aaaa;
这种
让我看着太累了，跟他说了别这么搞都不行

  不如在组合逻辑里先赋值，然后单独在时钟沿寄存。

条件化到最简，没啥错吧。关键是贵小同学做设计，目的是服务于综合器，还是服务于人。服务于人，就当我没说。

小同学把这种逻辑的写到if里面，要tjjtds，让验证人员很头疼的。
现在综合器很聪明的了。简化多了可能是无用功还容易出错。要在可维护性上做些考虑。闲的没事干了，就当我没说
建议rtl code review应该纳入ic设计，还是很有用的很有效的，能人肉发现一些问题的。不过关键还得看团队和团队里的人怎么样（不怎么样就检查coding风格得了）。

阅读《片上系统——可重用设计方法学（第三版）》