刚毕业的时候，我年少轻狂，以为自己已经可以独当一面，庙堂之上所学已经足以应付业界需要。然而在后来的工作过程中，我认识了很多牛人，也从他们身上学到了很多，从中总结了一个IC设计工程师需要具备的知识架构，想跟大家分享一下。

I. 技能清单

作为一个真正合格的数字IC设计工程师，你永远都需要去不断学习更加先进的知识和技术。因此，这里列出来的技能永远都不会是完整的。我尽量每年都对这个列表进行一次更新。如果你觉得这个清单不全面，可以在本文下留言，我会尽可能把它补充完整。

• 语言类
  • verilog-2001/ Vhdl
  • SystemVerilog/ SystemC
  • Makefile/ Perl/ Python/ Shell
  • Tcl
• 工具类
  • NCVerilog/ VCS/ ModelSim
  • SimVision/ DVE/ Verdi
  • Vim/ Emacs
  • SVN/ CVS/ Git
  • Microsoft Office
• 平台类
  • Windows
  • Linux
• 其他加分项目
  • MATLAB
  • ISE/ Synplify/ Vivado/ Quartus
  • LEC/Formality
  • VMM/ UVM
  • ESL
  • ZeBu Server
  • JIRA/ Confluence
  • C/ Assembly Language
  • Computer Architecture/ arm Architecture/ mips Architecture

II. 为什么 & 怎么办

A) Verilog-2001/ VHDL

这里之所有强调Verilog-2001而不是Verilog-1995，是因为在Verilog-2001中规定了很多新特性，因此可以产生更好的代码风格。我曾经在什么是良好的Verilog代码风格一文中对新版的接口语法进行过详细的举例说明。这种新的接口方式修改起来更加简单，例化模块的时候使用也更加方便，不像旧版的接口语法由于一个接口需要分3次描述，无端端增加了代码行数而且阅读和改动都很困难，尤其是当一个模块的接口数目超过一个屏幕的显示范围时Verilog-2001的这种优势更加突出。

学习Verilog最大的问题就是，很多国内的书写得都很不好，书中的很多例子都是为了说明语法特征而存在的，没有任何实用价值，甚至很多代码都是错误的（这里错误的意思并不是说他语法错误，而是说他是不可综合的，无法用数字电路来对等实现的）。所以，对于学习Verilog，我的建议是，随便找一本类似语法手册的书籍，匆匆把基本语法看过一遍，搞清楚模块定义，接口定义，模块例化，寄存器定义，线定义，always块怎么写这些基本内容后，就开始到OpenCores网站上去下载已经经过FPGA验证的完整开源项目代码进行学习。先做到看懂别人写的代码，然后再尝试自己去模仿，有不懂的问题再有针对性地去网上搜索答案。

Verilog语言与软件语言最大的区别就是，因为它是用于描述电路的，因此它的写法是非常固定的，因为电路的变化是非常有限的。学习Verilog的时候，很多时候我们并不是在学习这门语言本身，而是学习其对应的电路特征，以及如何对这个电路进行描述。如果心中没有电路，那么你是不可能写好Verilog的。从基础开始，一点点积累类似计时器，译码器这样的小型电路描述方法是非常重要的。Verilog鼓励在电路中进行创新，而不是在描述方法上进行创新。因此，即使是世界上最牛的Verilog高手，他写出来的Verilog代码语法也都是很普通的，而他的创意则在于如何去组合这些基本的小型电路。

举个不太恰当的例子，每个医生都会给你开药打针检查身体，但是高明的医生并不在于他用了多高难度的动作去给你扎针，或者给你开出什么奇奇怪怪的药吃，而是他如何快速准确的诊断出你的病情，用最合适的扎针吃药组合去治疗你。Verilog也是同样，要学会用最规矩保守的语法，写出运行速度最高性能最稳定的电路，而不是在语法上瞎费工夫。凡是你没见到别人写过的语法，都很可能是错误的。

VHDL虽然我并不是太了解，但是目前在欧洲很多国家，VHDL还是主流的RTL设计语言。VHDL语言的严谨性比Verilog要好，不像Verilog中一样存在大量符合语法却永远无法综合的语句，容易对新人造成误导（仿真通过的代码却在FPGA综合时报错，或者FPGA实现结果与仿真不一致）。而VHDL和Verilog虽然可以相互转化，但是转化过程中仍然存在很多问题，无法做到完全的自动化。关于这一点我之前写过一篇专题进行探讨：如何将VHDL转化为Verilog。有兴趣的同学可以去看看。

B) SystemVerilog/ SystemC

这两种语言都是为了验证而存在的。作为IC设计工程师，验证知识不是必须的，但是掌握基本的验证方法学有助于提高自己的debug效率和结果。我曾经在如何快速搭建模块验证平台一文中详细介绍过一种我自己总结的验证方法，这种方法就是基于SystemVerilog语法实现的。由于SystemVerilog对Verilog完全兼容，就像C++对C语言的兼容一样，所以SystemVerilog（或SV）学起来其实并不算难。

SystemVerilog是一种面向对象的语言，其设计的本意是用于搭建验证平台，主流的VMM/UVM方法也都是基于SystemVerilog实现的，所以立志成为IC验证工程师的同学，SystemVerilog的深入学习和流行方法论的学习都是必不可少的。

而对于那些只想做IC设计的同学而言，SystemVerilog同样也是值得学习的。且不说本文前面提到的用于提高验证效率的debug方法，即使只是为了做好设计，SystemVerilog也是大有用武之地。在欧美很多发达国家，很多世界顶级的IC设计公司内部都已经开始使用SystemVerilog进行RTL设计了。由于在SystemVerilog中加入了很多类似always_ff、always_comb等用于显式表明综合电路意图的新语法，代码的可读性更高，综合过程中也减少了歧义，尽可能地保证了综合结果与设计意图的一致性。

C) Makefile/ Perl/ Python/ Shell

以上四种都是IC设计工程师们常用的脚本语言，看起来似乎它们都跟IC设计的专业能力没有丝毫关系，但是由于本行业的专业工具价格非常昂贵，项目需求差异极大，因此掌握一门得心应手的脚本语言将对你工作效率的提升帮助极大。如果你还没有尝试过编写自己的脚本语言，那么问问你自己，有没有曾经为了完成一批仿真用例熬到深夜？有没有曾经因为要比对几万个数据搞到眼瞎？有没有曾经因为要修改一个全局信号的比特位宽而无比抓狂？要把一个hex类型数据文件转换为memory模型需要的特殊格式怎么办？没错，如果你掌握了脚本语言，以上这些奇奇怪怪的需求都不是事儿，重复而细致的体力劳动就交给计算机来完成吧。我一向信奉的口号就是：但凡做过一次的事情，就没有必要重复第二次。

如果你已经在工作中使用过其它工程师开发的平台或者脚本，那么它很可能是用这4种语言写成的。如果执行脚本的方式是make run，那么很可能你用到的是一个Makefile脚本；如果执行方式是source run，那么这应该是一个Shell语言写成的脚本；如果是其它情况，那么就得看具体这个脚本首行是怎么写的了。Makefile和Shell语言比Perl/Python要更容易上手，写起来也更加简单，比较适合满足一些非常简单的批量任务需求。Perl的强项则在于它强大的文本处理能力和无所不能的CPAN库，随时可以满足你的各种任性需求。Python的优点则是较好的可维护性。

关于脚本语言的重要性，大家可以到这里看看相关讨论：Perl等脚本语言在IC设计中有哪些用处？。

D) Tcl

严格来说，Tcl是一门非常单纯而简单的语言，而它的学习难点在于，只是掌握它的语法是远远不够的。这种情况有点类似javascript，如果你用js来开发网页，那么你必须深入了解DOM和HTML；如果你用js来开发游戏，那么你必须深入了解Unity3D引擎的各种知识；如果你用js来开发Web App，那么你必须会用node.js的各种库和常见的服务端框架。

语言永远只是工具，这句话放在Tcl上再合适不过了。在IC设计这个领域中，Tcl是一门非常常见的语言。他可以用于描述时序和管脚约束文件，UPF信息，也可以用来搭建简单的工作平台。它既是很多IC领域EDA工具默认支持的脚本语言，也是这些工具配置和输出的文件格式。因此，能够读懂Tcl，掌握Tcl语言的基本语法，就可以帮助你更好的使用EDA工具，真可谓是Tcl在手，天下我有！

但是，成也萧何败萧何，正如前文一开始提到的，仅仅掌握了Tcl的语法还远远不是全部。不同的EDA工具对Tcl脚本提供的命令和参数支持都是不一样的，每当你需要为一种新工具编写Tcl脚本时，都必须要熟读官方给出的用户手册，了解这种工具支持的Tcl命令结构，才能确保写出的脚本是可以被正确执行的。

E) NCVerilog/ VCS/ ModelSim

以上三种都是比较业界比较主流的仿真工具，其中NCVerilog和VCS都只支持Linux平台，而ModelSim貌似是同时支持Linux平台和Windows平台的。但是不管哪一种，我都希望大家能意识到两件事：第一，仿真器和波形查看器是两回事，本条目介绍的只是仿真器，仿真器的工作原理跟波形查看器是有天差地别的，同时由于IEEE对标准波形文件*.vcd格式的规范，任意仿真器都是可以和任意波形查看器组合使用的。第二，仿真器通常是没有图形界面的，为了更好地使用仿真器，你要熟读自己常用仿真器的用户手册，了解一些常见需求的命令行参数，至少要做到了解如下内容：如何指定编译的文件类型，如何指定编译文件清单，如何指定索引目录，如何指定仿真精度，如何指定临时的宏变量，如何指定语法检查的严苛等级，如何混合编译由多种语言写成的工程，如何调用不同波形生成工具的pli接口，如何配合SDF反标进行后仿等等。

不同仿真器的功能其实都大同小异，但是是不是只掌握一种仿真器就可以打遍天下无敌手了呢？当然不是。在实际的工程中，我们经常用到第三方IP核，有时候出于保密的需要，第三方IP核会以加密二进制文件的方式提供，加密二进制文件长啥样呢？它们一般以“*.vp”格式命名，文件的开头部分就是标准的Verilog语法，但是在一行注释之后就全部变成了乱码。通常乱码之前的那行注释会指定该加密二进制文件支持的仿真器类型。所以你看，如果你是一个重度VCS使用者，而有一天项目经理突然塞给你一个只支持NCVerilog的加密文件，你内心一定会有千万只草泥马呼啸而过。

F) SimVision/ DVE/ Verdi/ ModelSim

与上面的仿真器相对应，以上三种也是业界比较主流的波形查看工具。所有的波形查看器都必须支持标准波形文件*.vcd格式，但是由于*.vcd格式的存储性能并不好，冗余信息过多，所以各家波形查看工具都纷纷推出了自己独家支持的波形文件格式，如DVE的*.vpd，Verdi的*.fsdb，ModelSim的*.wlf, SimVision的*.shm等。通常波形查看工具独家支持的文件格式都具有较高的压缩率，举例来说的话，通常1G左右的*.vcd格式波形转换为*.vpd格式后只有40MB左右，而转换为*.fsdb后通常会更小，因此将标准波形文件*.vcd转换为其他压缩格式更加有利于数据备份。

如果希望在仿真过程中不生产*.vcd，而是直接生成压缩率更高的其他波形查看器专用格式，则需要调用对应工具提供的pli接口，同时配合测试平台代码中的系统函数调用（如$fsdbDumpOn等）来完成。

说了这么多，不要以为*.vcd格式就一无是处了，再怎么说这也是IEEE规定的标准格式，其他不同压缩格式的波形文件之间如果需要相互转换，一般都是要先转换为*.vcd后再转到目标压缩格式去的。另外，在芯片的量产标准化测试环节中，一般规定采用的激励文件格式也必须是*.vcd，所以不管你平时习惯使用什么波形文件格式，*.vcd的产生方法都是必须要熟练掌握的。

对不起，上一段最后一句是错的，近期负责量产方面的事情，对这一块终于加深了了解，实际量产测试环节中ATE环境目前主要使用的激励文件格式主要有两种，分别是*.wgl和*.stil。这两种文件格式与*.vcd及*.fsdb等是有本质不同的。*.wgl和*.stil格式是基于周期数和电平向量的波形文件，而*.vcd和*.fsdb是基于时间和变化的。换句话说，在*.wgl和*.stil里，你会看到类似“0101010100”这样的信号描述，他完整记载了所有信号随时钟周期数（而非时间刻度）的变化过程，如果你以10MHz的时钟频率来播放这个波形，那么他产生的信号长度就是10个100ns，如果你以100MHz来播放则长度为10个10ns，这就是基于周期数记录波形的含义。同时，在*.wgl和*.stil波形里，信号是以向量的形式完整记录的，假如波形里有2个信号，“11”，“10”，“00”这三个向量就表示第一个信号在连续的三个周期里分别是“高高低”，而第二个信号则是“高低低”，这就是基于周期数和电平向量的完整含义。与此相对的，在类似*.vcd这样的波形文件里，经常可以看到#1000 1signal这样的表述（此处的signal通常会用类似#这样的字符代表它的id号），它表示过了1000ns后signal变成了高电平。由此可见，*.vcd文件本质上是通过记录时间增量和信号的变化沿来表示波形的。

那么问题来了，平时我们的仿真结果都是基于时间的类*.vcd格式，如果量产测试的激励必须是基于周期数的类*.wgl格式，要怎么办呢？目前市面上有一些可以将*.vcd转换为*.wgl格式的软件工具，但是授权收费不菲，建议有可能的话，设计人员最好在设计测试激励时就考虑到这一点，通过脚本或者其它方式直接生成*.wgl文件进行交付，如果只能提供*.vcd格式，请确保激励波形可以按统一的固定周期长度进行切割转换，否则在进行波形格式转换过程中可能会存在大量反复工作和沟通问题。

G) Vim/ Emacs

经常看到一些Verilog新人提出这样一个让人啼笑皆非的问题：“请问一般Verilog编程用什么样的软件？

首先，Verilog是一种电路描述语言，它本质上可能跟电路图的血缘还更近一些，至少不应该把这个描述过程说成是“编程”。其次，写Verilog其实并没有什么专门的软件，大部分业界的工程师都是用Vim或Emacs这样原始粗犷的文本编辑器来写Verilog代码的，如果你愿意的话用Notepad或Texteditor来写也未尝不可，只是如果你有深入了解过Vim或Emacs的话，自然就会明白这么多人选择它们的原因所在——提高效率。

你去问Vim或Emacs的使用者，为什么说这玩意能提高效率，多半对方回你的第一句就是：因为可以丢掉鼠标啊。显然这样一个结论并不能让人信服，而实际上这也只是它们众多优点中的一个而已。那么究竟为什么可以提高编程效率呢？核心原因当然是，因为借助它们，你可以用编程的方式来编程！听起来优点拗口对不对，没关系，请听我解释。

举个例子：如果你设计的模块需要对外输出100个寄存器，每个寄存器的位宽等于他的编号，如果使用普通的文本编辑器，你需要手工写下output reg reg_0到output reg[99:0] reg_99这100行代码，即使用上复制粘贴，你也需要逐行手工修改每行代码里的信号位宽和编号。但是，如果借助Vim编辑器的命令功能的话，你只需要写下for ($i=0;$i<100;$i++) { print("output reg[$i:0] reg_$i\n");}，然后在同一行按shift+v，输入:!perl回车，然后就你能看到前面输入的那些代码被替换成了你本来想输入的100行内容。 以上是一个稍微复杂的例子，可能大家平时不一定会遇到这种需求，但是以下情况呢？ > 你是否曾经忘记在每行代码末尾加上”,”或”;”符号，编译失败后才发现需要逐行补上？如果使用Vim编辑器的话，只需要用shift+v选中需要修改的行，按下:’<,'>s%$%;%g就可以了，熟练之后整个过程不超过5秒钟。
> 你是否曾经在代码写完之后被老大臭骂一顿原因是你没有把所有的reg和wire定义都放到文件的统一位置（如第38行）？如果使用Vim编辑器的话，只需要使用:g%^\s*reg\s*%m 38加上:g%^\s*wire\s*%m 38就可以了。
> 你是否曾经被要求删除某个文件中所有的注释？只需要:%s%//.*$%%g就可以了。
> 你是否曾经需要把一个模块例化256次，然后因为每次例化的一点微小不同导致你不能直接使用for循环？没关系，用qq录像功能，你只需要操作一次，然后使用256@q就可以把你的动作自动重复256次啦。
> 你是否曾经遇到键盘坏掉了，“a”键经常失灵甚至没有反应？没关系，用:inoremap ‘ a把‘键重新映射为a键吧。

类似的例子简直数都数不完，更多内容参见与Verilog有关的Vim实用技巧。

所以说，使用Vim或Emacs最大的好处就是，你会感觉到你的大脑比手更忙，因为从你想清楚到代码写好只需要花费极短的时间。你可以把全部精力投入到代码的内容上，而不是代码输入这个机械的过程中，就好像用打字机代替毛笔的感觉一样。只要是你能用编程描述清楚的事情，Vim就可以代替你快速完成，而前提就是你要先学会大量的Vim命令和正则表达式，以保证你的表述能被编辑器正确理解。

G) SVN/ CVS/ Git

以上三种都是目前比较主流的“版本管理”工具。什么是版本管理？简而言之，就是一种用于记录和查询文件版本改动的工具，通常都会被部署在公共服务器上，以保证数据的安全和可恢复。在项目的开始阶段，首先需要创建好版本管理的根目录，然后由不同的工程师逐一把自己的设计文件首次加入到版本管理的各级子目录下。在项目执行的过程中，每当有人修改一个文件，都需要通过版本管理工具上传代码并注释改动内容，版本管理工具会自动检查改动内容与服务器上的最新版本是否冲突（冲突的意思即是说，在该工程师改动这个文件的过程中，有其它人也对该文件的同一行代码进行了改动并上传了新版本），如果没有冲突，则会自动将新上传的改动合并到当前最新版本，反之，则将冲突部分进行对比显示，让工程师手工判断应当如何合并冲突行的内容，解决冲突后可以再次重新上传。

SVN和Git都是跨平台的版本管理工具，其中SVN是必须在线工作的，而Git是可以离线工作的。当你需要上传代码的时候，如果你使用的是SVN，则你必须保证从你的计算机到服务器端的通信是畅通的，而如果你使用的是Git的话，由于Git有本机仓库的概念，在你没有主动与服务器端同步之前，所有版本管理都是在本机仓库上完成而不需要与服务器通信的，这样即使是在离线环境下也可以最大限度地保证代码版本的可恢复性，同时也节省了在移动环境下工作时的传输流量。Git是开源的，最早兴起于互联网行业，目前也有逐渐在其他行业里广泛使用的趋势，以之为基础的开源社区GitHub更是为它的繁荣起到了重要的推动作用。

CVS是一款比较老的版本管理工具，只能在Linux平台下运行，不支持目录的递归添加和重命名，用起来略有些麻烦，不过因为目前还有很多公司在用，所以这里也顺带介绍一下，并不推荐。CVS和SVN的最大区别还是版本号的命名思想，在SVN中，任何一个文件的修改都会导致整个工程版本号的更新，而在CVS中，版本号是跟随文件的。因此，在系统的某个时刻，SVN工程中所有文件的版本号都是相同的，而CVS工程下的每个文件都有一个自己的版本号。CVS的这种版本号设定会给工程管理带来很多麻烦，主要是如果有一天你想把整个工程恢复到之前的某个状态的话，要么是你曾经记录下了当时所有文件各自对应的版本号，要么是你记下了当时的准确时间，要么是你当时给所有的文件打上了标签，否则几乎是不可能的。而对SVN来说，你只需要记住当时整个工程的版本号即可。