猛一看,距离上次写日志已经两年时间过去了,那时候自己刚刚转行到IC,才开始学习了一些
verilog语言呢,呵呵。不知道为什么,当时对IC那么着迷。
说自己是做IC的,其实倒不如说自己是做逻辑的。在一个大公司里面,分工很明确,开发、验证、测试各司其职。做为普通开发人员,主要责任写模块详细设计报告,模块RTL代码,模块自测,模块自测报告,
FPGA综合,静态时序分析,协助进行FPGA原型验证,协助进行
后端综合,流片之后协助进行测试。大项目一个流程下来,几年是很正常的事,所以有时候都感觉做到吐。
两年来,说写过多少行代码,真的没意思,不同的人写同样的代码,差别太大。所以做开发的,我觉得就积累了两方面的东西。一方面:本领域内的一些知识,比如我做光传输的,就了解光传输的各种协议,872,709,798等等。另外一方面就是积累数字设计的经验,这个就有点意思了。现在项目大了,各种语言抽象度也越来越高了,所以数字电路的设计都快成软件开发了。IC设计工程师,要清楚的明白自己每写下一句verilog代码,代表的硬件电路是什么,这点对好多人来说可能已经显得有点陌生了。前两天部门内部在评审年度培训计划的时候,很多内容都是涉及到协议,芯片应用场景等等。唯独其中一个项目经理提到了基础电路的标准化、归一化问题,当时给我印象很深刻。如果作为一个IC设计工程师,对基础电路都不熟悉的话,大家应该都很难想象写出的代码还有什么好的代码风格可言吧......
说到代码风格,如果撇开目标器件,单纯讲风格,我觉得很难说清楚哪种好,或者不好。但是有了目标器件之后,通过对器件内部结构的了解,那么就可以大概的知道什么样的电路,应该要有怎么样的代码风格,这对FPGA格外重要。不同的FPGA厂家的芯片要求的代码风格会有差异,即使同一个厂家的不同等级芯片,对于代码风格的要求也不尽相同。
有了对基础电路的认识,以及对目标器件的认识之后,那么实现什么样的功能,就是如何利用这些基础电路来搭积木的问题了。我每一次都尽量要求写出来的代码具有可重用性,尽量的参数化,即使不能完全移植,也争取稍作改动就可以直接用。这样的话,代码自测、维护起来就比较简单,我只需要维护一个模块就行,而不需要重复劳动。
写完代码之后,最好利用一些语法检查工具检查一下代码中的语法错误,像nLint,spyglass等。这种规则的设立,每个公司都不一样,但是又大致都相同。
自测对开发工程师的要求其实是挺高的。其中比较麻烦的不是建立测试平台而是用例分解。用例分解的完备性直接关系到模块的功能的完备性。所以可以要求对这个用例分解表进行多人评审,从而降低风险。对于比较成熟的公司,测试平台一般都有相应成熟的平台,然后每个项目可能会稍作改变。对于一些小公司,也有可能每个项目,甚至每个人各自为政。