【转载】数字IC设计⼯程师技能树
I. 技能清单
作为⼀个真正合格的数字IC设计⼯程师，你永远都需要去不断学习更加先进的知识和技术。因此，这⾥列出来的技能永远都不会是完整的。我尽量每年都对这个列表进⾏⼀次更新。如果你觉得这个清单不全⾯，可以在本⽂下留⾔，我会尽可能把它补充完整。
II. 为什么 & 怎么办
A) Verilog-2001/ VHDL
这⾥之所以强调Verilog-2001⽽不是Verilog-1995，是因为在Verilog-2001中规定了很多新特性，因此可以产⽣更好的代码风格。我曾经在⼀⽂中对新版的接⼝语法进⾏过详细的举例说明。这种新的接⼝⽅式修改起来更加简单，例化模块的时候使⽤也更加⽅便，不像旧版的接⼝语法由于⼀个接⼝需要分3次描述，⽆端端增加了代码⾏数⽽且阅读和改动都很困难，尤其是当⼀个模块的接⼝数⽬超过⼀个屏幕的显⽰范围时Verilog-2001的这种优势更加突出。
学习Verilog最⼤的问题就是，很多国内的书写得都很不好，书中的很多例⼦都是为了说明语法特征⽽存在的，没有任何实⽤价值，甚⾄很多代码都是错误的（这⾥错误的意思并不是说他语法错误，⽽是说他是不可综合的，⽆法⽤数字电路来对等实现的）。所以，对于学习Verilog，我的建议是，随便⼀本类似语法⼿册的书籍，匆匆把基本语法看过⼀遍，搞清楚模块定义，接⼝定义，模块例化，寄存器定义，线定义，always块怎么写这些基本内容后，就开始到⽹站上去下载已经经过FPGA验证的完整开源项⽬代码进⾏学习。先做到看懂别⼈写的代码，然后再尝试⾃⼰去模仿，有不懂的问题再有针对性地去⽹上搜索答案。
Verilog语⾔与软件语⾔最⼤的区别就是，因为它是⽤于描述电路的，因此它的写法是⾮常固定的，因
为电路的变化是⾮常有限的。学习Verilog的时候，很多时候我们并不是在学习这门语⾔本⾝，⽽是学习其对应的电路特征，以及如何对这个电路进⾏描述。如果⼼中没有电路，那么你是不可能写好Verilog的。从基础开始，⼀点点积累类似计时器，译码器这样的⼩型电路描述⽅法是⾮常重要的。Verilog⿎励在电路中进⾏创新，⽽不是在描述⽅法上进⾏创新。因此，即使是世界上最⽜的Verilog⾼⼿，他写出来的Verilog代码语法也都是很普通的，⽽他的创意则在于如何去组合这些基本的⼩型电路。
举个不太恰当的例⼦，每个医⽣都会给你开药打针检查⾝体，但是⾼明的医⽣并不在于他⽤了多⾼难度的动作去给你扎针，或者给你开出什么奇奇怪怪的药吃，⽽是他如何快速准确的诊断出你的病情，⽤最合适的扎针吃药组合去你。Verilog也是同样，要学会⽤最规矩保守的语法，写出运⾏速度最⾼性能最稳定的电路，⽽不是在语法上瞎费⼯夫。凡是你没见到别⼈写过的语法，都很可能是错误的。
VHDL虽然我并不是太了解，但是⽬前在欧洲很多国家，VHDL还是主流的RTL设计语⾔。VHDL语⾔的严谨性⽐Verilog要好，不像Verilog 中⼀样存在⼤量符合语法却永远⽆法综合的语句，容易对新⼈造成误导（仿真通过的代码却在FPGA综合时报错，或者FPGA实现结果与仿真不⼀致）。⽽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等⽤于显式表明综合电路意图的新语法，代码的可读性更⾼，综合过程中也减少了歧义，尽可能地保证了综合结果与设计意图的⼀致性。从另⼀个⾓度来说，assertion的加⼊也极⼤地提⾼了代码的debug效率，⾮常有助于在⼤规模的数据交互过程中定位到出错的初始点，没有掌握的同学可以多花⼀些时间研究⼀下。
C) Makefile/ Perl/ Python/ Shell
以上四种都是IC设计⼯程师们常⽤的脚本语⾔，看起来似乎它们都跟IC设计的专业能⼒没有丝毫关系，但是由于本⾏业的专业⼯具价格⾮常昂贵，项⽬需求差异极⼤，因此掌握⼀门得⼼应⼿的脚本语⾔将对你⼯作效率的提升帮助极⼤。如果你还没有尝试过编写⾃⼰的脚本语⾔，那么问问你⾃⼰，有没有曾经为了完成⼀批仿真⽤例熬到深夜？有没有曾经因为要⽐对⼏万个数据搞到眼瞎？有没有曾经因为要修改⼀个全局信号的⽐特位宽⽽⽆⽐抓狂？要把⼀个hex类型数据⽂件转换为memory模型需要的特殊格式怎么办？没错，如果你掌握了脚本语⾔，以上这些奇奇怪怪的需求都不是事⼉，重复⽽细致的体⼒劳动就交给计算机来完成吧。我⼀向信奉的⼝号就是：但凡做过⼀次的事情，就没有必要重复第⼆次。
如果你已经在⼯作中使⽤过其它⼯程师开发的平台或者脚本，那么它很可能是⽤这4种语⾔写成的。如果执⾏脚本的⽅式是make run，那么很可能你⽤到的是⼀个Makefile脚本；如果执⾏⽅式是source run，那么这应该是⼀个Shell语⾔写成的脚本；如果是其它情况，那么就得看具体这个脚本⾸⾏是怎么写的了。Makefile和Shell语⾔⽐Perl/Python要更容易上⼿，写起来也更加简单，⽐较适合满⾜⼀些⾮常简单的批量任务需求。Perl的强项则在于它强⼤的⽂本处理能⼒和⽆所不能的CPAN库，随时可以满⾜你的各种任性需求。Python的优点则是较好的可维护性。
关于脚本语⾔的重要性，⼤家可以到这⾥看看相关讨论：。
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/ iVerilog
以上三种都是⽐较业界⽐较主流的仿真⼯具，其中NCVerilog和VCS都只⽀持Linux平台，⽽ModelSim貌似是同时⽀持Linux平台和Windows平台的。但是不管哪⼀种，我都希望⼤家能意识到两件事：第⼀，仿真器和波形查看器是两回事，本条⽬介绍的只是仿真器，仿真器的⼯作原理跟波形查看器是有天差地别的，同时由于IEEE对标准波形⽂件*.vcd格式的规范，任意仿真器都是可以和任意波形查看器组合使⽤的。第⼆，仿真器通常是没有图形界⾯的，为了更好地使⽤仿真器，你要熟读⾃⼰常⽤仿真器的⽤户⼿册，了解⼀些常见需求的命令⾏参数，⾄少要做到了解如下内容：如何指定编译的⽂件类型，如何指定编译⽂件清单，如何指定索引⽬录，如何指定仿真精度，如何指定临时的宏变量，如何指定语法检查的严苛等级，如何混合编译由多种语⾔写成的⼯程，如何调⽤不同波形⽣成⼯具的pli接⼝，如何配合SDF反标进⾏后仿等等。
不同仿真器的功能其实都⼤同⼩异，但是是不是只掌握⼀种仿真器就可以打遍天下⽆敌⼿了呢？当然不是。在实际的⼯程中，我们经常⽤到第三⽅IP核，有时候出于保密的需要，第三⽅IP核会以加密⼆进制⽂件的⽅式提供，加密⼆进制⽂件长啥样呢？它们⼀般以“*.vp”格式命名，⽂件的开头部分就是标准的Verilog语法，但是在⼀⾏注释之后就全部变成了乱码。通常乱码之前的那⾏注释会指定该加密⼆进制⽂件⽀持的仿真器类型。所以你看，如果你是⼀个重度VCS使⽤者，⽽有⼀天项⽬经理突然塞给你⼀个只⽀持NCVerilog的加密⽂件，你内⼼⼀定会有千万只呼啸⽽过。
如果你是⼀个开源⼯具的死忠粉，那么你可以考虑使⽤Icarus Verilog (iVerilog)进⾏仿真编译。iVerilog
编译器和其⾃带的vpp仿真器是基于C++开发的，⽀持Verilog全系列的IEEE标准，但遗憾的是，iVerilog⽬前对System Verilog的⽀持还相当有限。iVerilog是跨平台的，⽆论你喜欢⽤Windows, Linux还是OS X, iVerilog都提供了⾮常便捷的安装⽅式。
F) SimVision/ DVE/ Verdi/ ModelSim/ gtkWave
游戏开发工程师需要学什么与上⾯的仿真器相对应，以上三种也是业界⽐较主流的波形查看⼯具。所有的波形查看器都必须⽀持标准波形⽂件*.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⾥，你会看到类似“010*******”这样的信号描述，他完整记载了所有信号随时钟周期数（⽽⾮时间刻度）的变化过程，如果你以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格式，请确保激励波形可以按统⼀的固定周期长度进⾏切割转换，否则在进⾏波形格式转换过程中可能会存在⼤量反复⼯作和沟通问题。
同样的，如果你希望使⽤开源的波形查看器的话，gtkWave将是你的不⼆选择。和iVerilog类似，gtkWave也是跨平台的，⽽且简单易⽤，⽀持*.vcd标准格式，同时独家⽀持⾼性能压缩格式*.lxt和*.fst（gtkWave⾃带vcd转fst的转换器，只需在运⾏过程中加⼊参数调⽤即可）。
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键吧。
类似的例⼦简直数都数不完，更多内容参见。
所以说，使⽤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来说，你只需要记住当时整个⼯程的版本号即可。
H) ISE/ Synplify/ Vivado/ Quartus
ISE和Vivado都是Xilinx旗下的FPGA⼯具，其中ISE⽐较⽼，官⽅已经停⽌更新了，⽬前最新的版本是14.7，⽽Vivado作为新⼀代的FPGA ⼯具⼀直在继续更新。Quartus则是Altera旗下的FPGA⼯具，功能和ISE/ Vivado⼤同⼩异。笔者平⽇⾥对FPGA⼯具的接触并不多，但从有限的接触体会⽽⾔，Quartus⽐ISE/ Vivado更适合⽤于学习，⼊门的门槛更低⼀些，操作界⾯也更加简单易学（但千万不要使⽤6.2版本以下Quartus中⾃带的波形仿真⼯具，那是垃圾）。
学习FPGA有助于帮助⼤家理解“正确的设计 != 正确的RTL”，⽽是“正确的设计 == 正确的RTL + 正确的时序约束”这⼀重要理念（很多同学⼀直⽆法从软件编程的思维中跳出来，也是因为⼀直没能理解好
这个理念）。正确的时序约束通常包括管脚约束和时钟约束，任何⼀项约束出错都会导致综合出来的电路⽆法按照预设的频率和时序进⾏⼯作。Quartus⽀持的约束⽂件格式是*.sdc。ISE和Vivado⽀持的约束⽂件格式有所不同，ISE⽀持的是*.ucf，Vivado⽀持的是*.xdc，但由于Xilinx家的⼯具中内置了约束⽂件互相转换的脚本，因此只需⼀个命令就可以在两个软件的⼯程之间⽆缝切换。从时序约束的思想上来说，Quartus与ISE/ Vivado在很多细节上都有所不同，所以从⼀个平台迁移到另⼀个平台的过程中依然会有⼀个学习过程，例如说：Quartus在时钟定义上不太区分管脚输⼊时钟和内部时钟，但在ISE中则不允许使⽤管脚输⼊时钟直接驱动寄存器，⽽是必须⾸先经过BUFG/ PLL/ DCM等时钟IP处理后输出⽅可以使⽤。Quartus对于输⼊输出的同步数据信号偏移offset in/out和ISE的定义也正好相反，使⽤过程中需要尤其注意。最后⼀句话送给FPGA新⼿们，千万记住，如果你在设计FPGA⼯程的时候没有添加任何时序约束或时钟约束，请不要问我为什么电路⼯作不正确，本段话的第⼀句已经回答你们了。
在学习FPGA的过程中，掌握信号探针⼯具（signal probe)的使⽤是⾮常必要的，有了它们，⼤家就可以像在仿真软件⾥那样，把真实FPGA硬件⾥的物理信号采样抓取到波形查看⼯具中去进⾏debug。Xilinx家的信号探针⼯具叫ChipScope，⽽Quartus家的叫SignalTap。相对来说，SignalTap⽐ChipScope要好⽤很多，例如说，SignalTap抓取波形的时候，信号名称可以⾃动识别，⽽ChipScope会把信号名称⾃动命名为序号，需要⽤户⼿动使⽤别名进⾏修改，⽽其中⼀旦有⼀个信号名称写错，就得把该信号以后的全部信号名称重新输⼊⼀次。
I) Windows/ Linux/ OS X
相信⼤多数⼈的个⼈计算机使⽤的都是以上系统或类似以上系统的其他系统吧。以上3个系统，对于专业的数字IC前端设计⼈员⽽⾔，⼯作的⽅便程度（注意，是专业⼈员的⽅便程度，⽽⾮学习曲线的陡峭程度，这⾥是指均已达到熟练掌握的前提下对于⼯作效率的帮助）由⽅便到困难分别是：Linux > Windows > OS X。在Windows下，你可能需要的⼯具有Cygwin（模拟Linux shell，带有⼤部分GNU⼯具），Modelsim，Debussy(更名Verdi后的版本没有对应的Windows版本), Quartus, ISE等。在Linux下，你可能需要的⼯具包括Bash/Csh/Tcsh，Modelsim，Quartus，ISE，VCS，Simvision，DVE，NCVerilog，Formality，LEC,Synplify等。⽽在OS X下（笔者不幸就位于该平台下），你可以使⽤的⼯具就只剩下Bash/Csh/Zsh，iVerilog，gtkWave这些选择了。
从以上内容不难看出，在⼯具的多样性⾓度⽽⾔，Linux完爆其它平台，这也是为什么绝⼤多数IC开发公司的服务器都选择部署在Linux下的主要原因之⼀。对于个⼈电脑⽽⾔，⼤部分同学会选择使⽤虚拟机来兼顾不同平台的⼯具选择，个⼈建议⼤家最好在熟练掌握Linux平台及其⼯具的前提下，同时也了解⼀下其它平台的解决⽅案（如果你有在MAC OS X平台IC开发⼯具的使⽤建议或者问题，欢迎来稿）
附：数字IC⼯程师的技能树
今天与同事聊起了IC⼯程师的修养等问题，结合不久前的⼀个想法，总结成⽂，抛砖引⽟，欢迎讨论和补充，转载请注明。
RTL语⾔仅仅就是Diablo⾥⾯⼥巫的⽕球。。。是⾸个技能，但你升到20级也就是个⽕球。。。当然对别的技能是有加成的哦
其他主要技能是，
算法逻辑设计与IP集成评估:
设计的要求基本要看得懂算法⽂档做实现，定点化和⼀些数学基础。特定模块的集成要求⼀般有相应知识背景，遇到问题能够debug进去。
SoC逻辑设计与IP集成评估:
总线，DMA，或者⼀些挂在总线上的内部设备
接⼝模块逻辑设计与IP集成评估:
DDR,HDMI，Tunner,AFE,⼀些⾮数字信号或者Phy的接⼝，通常都会从I2C⼊⼿，不要光盯着逻辑哦，也可以看看上拉电阻的阻值是怎么算的么，这块上板调试的时间会⽐coding时间长的多。。。
Chip Level模块设计:
这个基本每颗芯⽚都是独特的，也是关键的，涉及到clock gen, pad 复⽤,power domain控制，测试模式等等⼀堆很杂但很关键⼜没有⽅法学保证的问题脚本初步:
perl TCl ⾄少能够翻着骆驼书写个⾃动⽐对脚本啊什么的吧
验证初步:
模块级别的验证还是需要做到的，SV，assertion等等
ASIC前端流程:
Synthesis STA DFT MBIST FM CDC 做到能够从RTL到交付Netlist算是本级别升满
板级调试能⼒:
LA ⽰波器等等基础的仪器，和你所设计模块的周边电路，FPGA的流程
软硬件协同调试:
这个技能我还没有加过点。。。但觉得应该是属于⽕墙这种关键性的能⼒。。。
C语⾔初步:
有想法改算法吗？matlab⽐较灵活，C的效率⽐较⾼
⽂档阅读写作与Presentation能⼒:
怎么迅速理解别⼈的思想和表达⾃⼰是⾮常重要的，在⼤项⽬⼤公司中尤其重要
背景知识基础:
这个算是被动掌握型的技能，每提⾼⼀级，各个技能都相应5%的提⾼。。。包括数字集成电路设计本⾝,Rabaey那本书可以不时的看看，是否有时会有恍然⼤悟的感觉
关于背景知识基础，数据通信，移动通信，多媒体，和消费类电⼦相关的⼏⼤⽅向都可以作为⼀门单独的背景知识树，这个技能树往往算法⼯程师加的点数⽐较⾼，设计⼯程师多看看相应的知识对于融会贯通和进⼀步提⾼也是有很⼤帮助的。数学分析和统计学是这个技能的基础。
写着写着就发现其实IC设计和Diablo还是有不少相通之处的 -_-b
体⼒就是体⼒。。。没体⼒就挂了。。。
法⼒是勤奋，⼀遍遍的施放技能对项⽬进⾏攻击，要求你有⾜够的法⼒。
敏捷是悟性，没有悟性，脑⼦转的不快，你的攻击往往miss。。。
⼒量是沟通，这个单独看有点牵强，和我想把公司的制度⽂化⽐作装备有关系。。。⾄少要拿的动装备么（融⼊公司）
⼤家做项⽬就是打怪，杀怪涨经验升级加技能，捡钱。。。
好的公司⽂化和制度就是好的装备，虽然个⼈很重要，但装备也是刷怪的关键。
⼤家要配合刷怪，设计是⼥巫，单⼈的⼒量刷个普通还⾏，恶梦和地狱遇上魔免的，就挂吧。
验证是死灵。。。好的验证环境和结构(毒和诅咒)能把打怪的难度降低
项⽬经理是野蛮⼈。。。会吼⼤家。。。但是也是⾁盾，直⾯项⽬压⼒。。。
每⼀代Diablo都有新的职业兴起，2加⼊了死灵，如数字时代崛起了验证⼀样，Diablo3 也多出来猎⼈等职业(MEMS?呵呵)，但这不影响每个职业都去努⼒提⾼⾃⼰的技能，为刷怪贡献出⼒量，衷⼼的希望⼤家都能够乐在其中。
原⽂地址：kellen.wang/zh/the-knowledge-base-of-a-qualified-ic-design-engineer/

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。