前言

我刚入职的时候也有这样的疑问，因为三年没写过一行verilog。在网上的得到答案基本是：

1. 学好Verilog；
2. 要掌握FIFO；
3. 时序处理等等。

但是这些答案在我工作的两年内，发挥的作用聊胜于无。

思来想去，数字IC前端设计（以下简称设计）好像没有快速提高的方法，因为不同的方向差别比较大。抛开编程语言，设计的基础是协议，不同方向的协议基本不同。验证初期不懂协议也能做，把设计当成一个黑盒，根据接口写代码。但是设计不行，不懂协议连设计文档都没法写。

所以本文仅分享我对设计的理解，快速提高大概谈不上。

岗位要求

在芯片设计的不同方向上，对工程师的知识体系和技能要求不一样。后端和SoC咱没做过，不了解。以我现在的岗位，数字IC设计（video）为例，该岗位对新手的大致要求是：

1. 根据C模型，进行RTL实现；
2. 会基本的验证，以方便配合DV工作。
3. 简而言之，IP设计是算法RTL化。

IP设计类的ASIC岗位（ISP/Display/Video）应掌握以下事项：

1. 懂协议；
2. 根据协议和C模型，归纳总结，将协议硬件化，写设计文档；
3. 根据文档，写RTL化代码；
4. RTL设计实现的优化；

1. 协议

ASIC设计岗位工作的本质是协议RTL化。协议是基础，不懂协议，一切是空谈。协议如果简单，可能需要懂全部；如果复杂，只需要懂自己负责的那一块即可。

入职以后，我一直在啃协议，做项目期间也是一边做，一边啃。此外，协议和C模型并非完全相同，协议只是抽象，具体的算法实现和RTL编写要以C模型为准。

2. 设计文档

设计文档的内容包括：

1. 模块框架图
2. I/O接口
3. ram说明
4. 状态机
5. 模块功能流程图
6. 协议实现重点的说明

文档的意义不仅是给DV和算法看，同时也是整理思路，给自己看。

有些大佬可以不写文档，照着C模型直接写RTL，但是我不建议新手这么做。写完两星期之后，大概率忘记自己之前如何实现，为什么要这么实现。

从抽象层级来说，设计文档＞协议＞C模型＞RTL代码。有时候几千行的RTL，用几句话就能描述完。如果没有文档直接看RTL，自己debug会相当耗时，也不利于后续DV的工作。

文档尽量写的充分些。我见过意识流的文档。虽然是英文的。但是基本是Chinglish。通篇只有框架图和接口表比较有用，真研究起来，不如直接看代码。

如果项目紧急，来不及整理文档，可以将要点记录下来，写上关键词，方便项目结束后回溯。

3. 协议RTL化

先按照C模型，堆code实现功能，然后跑通一个case即可，优化后续再做。从0到1是一件不容易的事情。应届生进入公司，一般要么有人带，要么有已完成的项目可以参考。这也体现了团队成熟的重要性。

协议和C模型在设计时是否有考虑硬件优化，直接决定了编写RTL的难度。软件思维和硬件思维差别巨大。

协议和C模型也存在对不上的情况，这时候就需要具体分析，有可能是C模型错了，也可能是协议错了，亦或者是自己理解错了。

算法认为在后台使用了一个简单的数组，然而在硬件用需要一个寄存器堆，大了就得用ram。而且如果一个多维数组使用的不充分，对于ram设计压力是比较大的。如果按照C模型设计，会有相当多的浪费；如果采取数据连续排列的方式，时序比较难做，读写控制逻辑也会比较复杂。

4. RTL设计实现的优化

优化是门艺术，作为菜狗，我能做的也不多。而且这是一个循序渐进的过程。遇到的问题和情况多了，会积累到足够的感性素材，然后整理成理性素材。

只有深入研究协议和C模型，并且搞懂了算法的实现规则，才好有的放矢。

C模型的设计，大多是按照软件思维设计的，有些设计对硬件不友好，甚至浪费存储空间。虽然功能是跑通了，但是并非最优解。有些数据在C模型中是用5bit表示，但是硬件实现用3bit，甚至1bit就够。

协议不断的在更新，有些子模块在新老协议中的功能相近，那么以前的逻辑可以直接复用或者微调代码即可；但是有些子模块的功能前后相差很大，这时候需要考虑计算单元和存储单元如何复用。

如果同一块的buffer变的超大，那么可以考虑新增一个ram，老buffer给其他功能单元或者子模块复用；如果同一块buffer小了很多，可以将老buffer做拆分，多的部分给其他模块复用。

以上是我的经验之谈，仅供参考。不同的设计方向的要求不一样，所以具体情况请具体分析。