在每年找工作的时候，在校学生就会分割成软件岗位和硬件岗位两大阵营。心仪软件岗位的同学就是专注于各种算法和语法宝典；而立志硬件岗位的同学则会专注于数字电路、模拟电路、单片机、FPGA。出现这样的情况，一方面是因为个人兴趣和工资收益使然，另一方面也是因为公司招聘岗位的刻意引导。

　　哪怕是对软件和硬件都有涉猎的同学，也不得不在软件和硬件之间做出选择。但实际工作中的岗位远不是硬件和软件这么简单的划分。现在，推荐一个需要涉猎软件和硬件的岗位——集成电路系统建模工程师。

　　1.集成电路设计流程方法的演进与软件对于集成电路设计的作用

　　从60年代集成电路出现到今天，集成电路设计流程经历了三次较大的变革。每一次变革都使得软件在集成电路设计中起到越来越大的作用。

　　1.1专业分工：前端设计和后端设计

　　在最开始的时候，集成电路的设计完全依赖于基于标准器件的手工操作。工程师需要自己绘制电路版图，再交付制造工序。在这一时期，模拟集成电路和数字集成电路在设计流程上的区分还不明显。

　　图1. 手工绘制版图（来源：网络）

　　这种方式显然不能适应大规模集成电路的设计。随着设计流程分工细化，出现了“前端+后端”的设计流程。前端设计侧重于逻辑设计/功能设计，将一个想法转化成逻辑电路的原理图。后端设计侧重于物理设计，将这个电路转化为可以制造的版图，包括布局、时钟树、布线、设计规则检查等等。前端设计完成并且验证通过后，将原理图提供给后端设计；后端设计完成并且验证通过后，将版图交付制造工序。

　　“前端+后端”的设计流程对于数字集成电路和模拟集成电路是通用的。对于数字集成电路，前端设计和后端设计已经演化为了相互独立的两个部门。公司内部也常常按照前端设计（逻辑设计）和后端设计（物理设计）划分部门。前端设计更侧重于逻辑设计（与或非的布尔逻辑），不需要考虑物理设计的细节。不过模拟集成电路并没有非常彻底的前端和后端分工。前端设计和后端设计都需要充分考虑晶体管半导体特性以及布局布线的细节才能够满足设计规格。

　　图2. “前端+后端”设计流程

　　“前端+后端”也是一个相互迭代的过程。如果后端工程师发现无法满足设计规格的时候（时序违例、面积过大、功耗过高等），可能会要求前端设计进行相应的调整。随着工艺的进步和芯片设计参数的提高，这种反馈越来越强。

　　设计流程的发展和巩固还依赖于流程化的电子设计自动化（EDA）工具的出现。龙头EDA工具商都提供全流程的EDA工具链。这些工具链能够满足设计者从想法到流片的全部设计和验证流程，甚至可以引导设计者完成设计。Synposys公司的EDA工具牢牢占领着国内数字集成电路的市场，DC+VCS和ICC+PT+VCS是国内大部分设计公司的标配。Cadence公司的EDA工具在模拟集成电路设计和数字电路设计后端市场，尤其是数模混合芯片市场具有不可替代性。毕竟Cadence是做后端工具起家的。FPGA的设计工具也是类似的情况，Intel的Quartus和Xilinx的Vivado都能够引导用户完成一次完整而有效的设计。

　　“前端+后端”已经成为集成电路设计的主要流程，迄今没有颠覆性的变化。目前设计流程的发展趋势可以概括为：提高EDA工具的自动化程度，减少人工干预和接入，降低设计门槛，提高生产率。

　　1.2提升自动化程度：芯片设计软件化

　　在硬件描述语言（HDL）出现之前，前端设计和后端设计的接口就是原理图。但是设计一个复杂电路的原理图是非常辛苦和耗时的。目前，HDL已经完全取代了原理图作为前端设计的载体。前端工程师将设计想法转化为HDL描述。随后，综合工具将HDL描述转化为网表。网表用标准单元的连接描述电路。前端设计和后端设计的接口接受用HDL语言描述的网表。常用的HDL语言就是Verilog和VHDL。

　　HDL的出现，让前端设计师得到了充分的解放，也让数字集成电路设计出现明显的软件化趋势。

　　首先，从形式上，HDL代码与计算机软件程序非常相似。不过这里必须要说明，HDL代码与计算机软件程序有明显的区别，即便是在行为级描述。HDL代码是对电路行为或者连接的描述，而不是类似于软件程序那样的可执行程序。相对于软件语言，HDL语言特别加强了对于并行化的描述和位运算的描述。以Verilog HDL为例。在Verilog中，赋值分为阻塞赋值和非阻塞赋值，以描述信号之间的并发关系。Verilog相对于高级软件编程语言，补充了比特级别的信号类型。

　　其次，HDL代码可以通过脚本来生成。HDL代码的呈现形式是文本文件。这就使得，可以用脚本程序（比如python，perl等）来生成一个有规律的HDL代码文件。通过脚本生成的HDL代码经过综合之后得到的电路，会与行为描述产生的电路等效，甚至会比通过行为级描述产生的电路更加简化。这是因为，HDL代码的不同写法只是对相同电路功能的不同描述而已。只要功能（输入和输出的对应关系）一致，那么综合得到的电路就是等效的。比如，对于一个8比特数除3求余数和模数。直接的想法是写一个除法器按照移位减法进行计算。同时，也可以写一个脚本，直接生成256个输入对应的输出，并用case结构写成一个Verilog模块。生成的脚本综合出的模块就是一个组合逻辑。综合工具会使得电路结构最简。这一种策略在实际工程中经常遇到。

　　此外，HDL代码是可以直接仿真的。但是，仿真是串行执行的，所以HDL语言还要规定大量的仿真规则以规定HDL代码在仿真时的行为。在仿真时，EDA软件借鉴了软件的概念来提供调试功能（单步调试、信号值等）。这使得HDL代码更加类似于软件，也使得HDL代码的概念变得混乱。

　　1.3 SoC设计方法学：IP核和“攒”芯片

　　随着芯片集成能力的提升，由一家设计公司完成电路中所有模块开发的成本显著提高。模块的定义、开发、验证是一个消耗时间和人力的工作。另一方面，随着SoC设计方法学的流行，芯片内部的组成模块也越来越趋同。一款SoC芯片内部一般都由CPU核、片内互联、片内存储、DRAM接口、USB接口等基本模块以及各种慢速外设组成。这就使得不同设计公司之间可以复用设计。

　　在这样的背景下，产生了一类IP供应商。这些IP供应商为设计公司提供充分验证过的成熟的IP模块。设计公司向IP供应商支付可观的费用（仍然可能低于设计公司自行开发模块的成本）。最典型的IP供应商就是ARM了。这家公司通过向全球的SoC厂商提供处理器核、片内总线等相关IP核，不仅成功的存活了几十年，还牢牢占据了全球嵌入式处理器的市场，不容Intel染指。当然，ARM的IP税也是让各大公司有苦难言。Synopsys和Cadence也在IP供应市场产生可观的份额。

　　IP核的出现、成熟和丰富，产生了一种新的芯片设计形式，即“攒”芯片。设计公司只需要专注于自己的芯片中独到的部分，并做到有亮点盈利。其他部分都可以通过购买各种IP获得。比如一款实现某种算法的SoC，其中的算法模块是公司的独到专利，由设计公司自己设计、验证并优化。这款SoC中的CPU核（作为交互控制接口，运行固件）、片内互联、视频编解码、内存接口以及视频接口都可以通过购买IP获得。

　　总而言之，集成电路设计流程的最大的特点就是分散和专精。从设计到制造，需要经过很多公司的接力才能完成。从IP提供商、EDA工具商、设计公司到制造商，每家公司都可以决定最终芯片的质量，却又不能保证最终芯片质量。反过来，对于设计公司来说，使用已经经过充分验证的流程和IP，可以显著降低公司自己的研发成本和风险成本。对于小公司以及创业公司，尤为如此。对于大公司而言，出于供应链安全性和定制化的考虑，可能会在IP核上进行布局，但是一般不会布局EDA工具。

　　在片上系统的设计流程中，模型的地位得到了重要的提升，尤其是对于完整系统的建模。相对于单一功能的芯片，片上系统的复杂度空前的提高，完整走完一块芯片的“前端+后端”流程是非常耗时而且非常昂贵的。设计公司显然不能为所有的设计方案都实际做一次流片，也不可能用一次次流片来修正设计方案的缺陷。因此，设计公司纷纷用模型研究来进行设计方案的探索和评估。一方面，开发建模的成本要低得多了，而且模型的灵活性高，迭代速度快。另一方面，模型能够反映设计特性。基于模型仿真的分析结果能够反映设计的实际情况。

　　2.设计流程向前延伸——建模

　　“前端+后端”的设计流程是以详细的和完整的设计规格书为起点的。前端工程师将设计规格书转化为HDL描述，继续完成整个设计流程。这确实是一个很完备的设计流程。

　　不过，如果设计规格书就定义错了或者定义不完善呢？在芯片功能较为简单、设计规格较为明确的时代，可以在验证阶段（前端验证或者后端验证）发现设计规格不能满足设计需求。进而反过头来修改和完善设计规格书，再重新进行设计和验证的迭代。但随着集成电路规模的不断提高，“设计+验证”的迭代周期变得很长。如果到了验证阶段才发现技术路线错误，这样浪费的人力和时间成本就太大了。因此，如何验证设计规格是否正确就变得至关重要了，因为这决定了后续的工作是否在正确的道路上前进。

　　2.1建模的目的

　　在进行复杂集成电路设计时，对将要设计的集成电路进行建模验证成为了保证集成电路设计不犯“方向性错误”的不二选择。对集成电路进行抽象建模的目的可以归纳为三个方面。

　　第一个方面，通过软件仿真研究建模对象的性质和规律。这里需要研究的规律包括物理特性的规律，比如晶体管的电路模型、功耗模型等。还需要研究的是需要实现的功能的参数特性。通过模型仿真，可以得到某一个参数与某个性能指标的定量关系。对于复杂的系统，这种定量关系往往都是无法通过公式直接计算得到显性的解析结果，必须要依靠仿真模型经过多次迭代和逼近后得到数值结果。

　　举一个分析截断误差的例子，以Cordic算法进行单精度浮点数的开方运算（仅作为举例，浮点数开方一般不用Cordic算法）。单精度浮点数有23位尾数，组成1位整数和23位小数的定点数。如果直接以这样的精度计算，那么平均误差相当于最后4个比特是无效的。为了能够降低误差，需要对参与中间计算步骤的定点数扩展为1位整数和30位小数的定点数。计算完成后，再截断为符合单精度浮点数定义的尾数。中间计算步骤的位扩展具体参数就需要通过建模和仿真来加以验证。

　　另举一个片上互联的例子。在片上网络中，路由器中的缓存大小对于网络吞吐率的影响虽然可以用一些理论模型来加以描述，但是这类模型通常只能给出吞吐率的上界。通过模型仿真，可以明确的得到缓存大小与网络吞吐率的量化对应关系。

　　第二个方面，建模可以对设计方案和设计规格进行初步验证或并以此为基础探索更优的设计方案。在架构设计阶段，可以快速实现多种设计方案的模型，并且通过模型仿真设计方案的特性，明确哪种设计方案最具有继续研究的价值。在这一方面的应用中，模型验证多用于参数选择，比如确定算法中参与运算的各个变量的精度、网络中缓存的大小、神经网络的规模等等。

　　再举一个架构设计的例子。多核异构芯片中的片上互联结构设计时，需要满足一些核心之间高密度数据流传输带宽需求。这就使得，同构的片上网络结构和路由算法不适用，而设计新的拓扑结构和路由算法能否真正达到设计需求就需要模型仿真来为其背书。

　　另外一个例子和工程密切相关。商业公司虽然可以从公开发表的学术论文中寻找设计方案，但学术论文在应用环境和验证环境上常常语焉不详。虽然学术论文都宣称自己取得了显著的参数提升，但是并不意味着这些方法都可以利用到的某个特定的设计中。如何甄别出对具体设计有价值的方案，也是模型的重要作用。

　　第三个方面，超前软件开发。当下的大部分芯片都不再是完成某个固定功能的简单模块，而是一个集成在芯片上的完整系统。即便是为某一个单一功能的芯片，其中也通常集成了某种轻量级的CPU核来实现参数配置、数据交互以及功能管理，如蓝牙芯片CC2640、充电器管理芯片SE8A等。所以，当下的芯片，大多常常需要固件、BIOS、OS等软件配合。

　　按照传统的开发模式，这些软件的开发都只能在集成电路设计完成之后进行，最早也需要在FPGA原型验证时进行。这不但造成软件开发进度的延迟，软件工程师也无法对集成电路的设计提出有效的意见。只能是硬件有什么，软件就用什么。这显然不是一种最优的开发方法。

　　而基于硬件模型可以将软件开发的工作提前到与硬件同步进行。在硬件工程师按照模型设定的设计规格进行硬件开发的时候，软件工程师也可以在这种模型上开发相应的软件，并且运行调试。

　　更为重要的是，由于软件工程师通过模型在设计早期就参与了芯片的设计，软件工程师可以对芯片的软硬件功能划分和软硬件接口提出有价值的建议。这些改动对于芯片设计完成后的软硬件联合优化可以起到非常重要的作用。

　　2.2建模对于设计流程的影响

　　建模可以贯穿在集成电路的设计流程，但是建模工程师则更多的出现在设计流程的早期，也就是在设计方案确定之前。

　　下面以实现某种算法型的SoC芯片为例来看一下建模工程师如何参与集成电路的设计。

　　2.2.1建立算法模型

　　在这款芯片的研发早期，建模工程师对芯片使用的算法建立模型，并且对算法模型进行仿真。这一过程中，验证了算法的正确性和可行性。这时的算法模型是理想的。

　　接下类，考虑电路计算过程中引入的截断误差，也就是引入计算的精度。通过调整参与计算的数据的宽度，保证最终结果的精度也满足要求。这样就得到了算法的功能模型。也就说，这个功能模型输出的结果应该是实际硬件电路输出的结果相同。

　　再次对模型进行细化，考虑到计算电路的时序特性，并且补充算法模块的输入和输出接口时序。这样就得到的算法的时序模型。

　　通过上面的建模过程，完成了对算法的探索，得到了算法的设计规格。接下来，就可以接入集成电路设计的前端流程了。硬件工程师可以根据模型探索得到的设计规格重新编写HDL描述。随着高层语言综合技术（HLS）的发展，硬件工程师也可以通过HLS工具将模型直接转化为HDL描述。

　　2.2.2建立架构模型

　　这款算法芯片其实是一款SoC芯片。公司设计的算法模块需要添加到一种CPU框架中，作为CPU核的一种外设或者协处理器。这里需要取舍的架构问题，例如：算法模块集成到CPU核的哪一个层次（可以作为CPU核内部运算单元、CPU外部共享私有内存的协处理器、CPU核外部总线上挂载的独立设备等）？CPU核如何调用该模块（中断/查询/DMA/独立访存）？SoC需要为算法模块提供多大的内存带宽？架构模型可以对这些问题给出量化的评估。

　　硬件工程师可以使用IP核来复用成熟的设计。建模工程师也可以使用虚拟IP（VIP）来复用成熟的设计。虚拟IP由IP提供商、EDA厂商或“第三方”针对某种IP提供。VIP应与IP功能和时序相同。建模工程师将VIP与公司自己的算法IP的模型组合在一起，就得到了SoC的架构模型。基于架构模型进行各种仿真，例如运行各种标准的测试程序，就可以对于以上提到的各种问题加以验证和评估。

　　同时，软件工程师也会参与到这一个过程中。软件工程师开发的固件可以在架构模型上运行，并且模拟对算法模块的调用过程。因此，软件工程师能够对硬件和软件功能的划分和接口给出有价值的改进意见。

　　2.2.3 建立验证模型

　　模型并不是只用于设计流程早期进行算法设计和架构设计的时候，算法模型和架构模型适当加以改造后还可以成为验证阶段的黄金（golden）模型。在相同的激励下，如果模型和设计提供相同的结果，那么设计是正确的；反之，设计存在缺陷。黄金模型也提供了设计中的关键点的中间结果。这些中间结果在模型和设计中都可以找到，可以方便用来调试设计的缺陷。

　　还有一种模型的目的是为了实现软硬件联合仿真验证。在设计流程中，除了使用测试向量验证设计模块是否正确，还需要验证模块能否使得实际系统满足设计要求。对于流水线上的一个队列缓存，测试向量只能验证这个缓存能够正确的读写数据，但是无法验证这个缓存是否会成为流水线的瓶颈，进而影响流水线的吞吐率。

　　此时，系统中的其他模块也同样处于开发和验证流程当中，显然不可能为了验证这一个模块而搭建一个完整系统。另一方面，随着集成电路规模的扩大，FPGA原型平台的性价比越来越低。能够容纳大规模设计的FPGA原型平台的价格也是相当可观的。因此，最好的验证办法是将模块放到由软件模型构成的系统中。被测模块以RLT代码和FPGA原型的形式出现在验证平台中，系统中的其他模块以软件模型的形式出现在验证平台中。软件模型向被测模块注入符合实际情况的激励，并且响应被测模块的输出。通过软硬件联合仿真环境，建模工程师可以获得设计模块对于完整系统的影响，评估设计模块能否使得完整系统满足设计要求。

　　2.3使用系统建模优势

　　系统建模的核心优势就在于一个“快”字。

　　系统建模仿真速度快是因为模型省略了一些功能特性和物理实现细节，那么系统模型仿真的速度肯定快于RTL编码仿真的速度。这是因为RTL仿真是比特级别的，而软件模型仿真是信号级别的。比如，RTL仿真需要仿真加法器中每一个比特的动作；软件模型则只需要一条加法语句即可。其次，对于非定长结构，软件可以用循环实现，并且只进行必要的循环；硬件不支持非定长结构，只能按照最大可能的结构展开，再通过使能关闭不需要的单元或者放弃不需要的结果。这导致RTL仿真时需要做大量冗余的运算。最后，RTL仿真是4值的（0,1,X,Z），软件仿真是二值的（0,1）。

　　当然，模型的精度（尤其是时序的精度）和速度是一对矛盾体，在提高仿真速度时必然会导致精度有一定损失，需要建模工程师根据建模的目的进行平衡。

　　开发速度快也是“快”的另外一方面。编写软件的成本要小于编写硬件实现的成本。软件和硬件开发的时间可以分为编写代码和调试bug。由于HDL不能支持可变循环等不定结构，所以硬件HDL的表达能力要远小于软件的表达能力。而且，由于调试方法的限制，调试软件错误要比调试硬件错误容易得多。尤其是对于编码过程中引入的bug，软件调试要比硬件调试简单很多。

　　3. 系统建模工程师

　　最后回到系统建模工程师的话题。系统建模工程师在设计公司中的人数不多，但是很重要。设计公司拥有的建模团队的实力从一定程度上可以反映公司未来技术演进的实力有多强。有些公司没有独立的建模团队，而是在架构团队、设计团队和验证团队中分散设置建模岗位或者人员。岗位的名称也并不统一，只能通过岗位职责和技术要求判断。附录中列出部分公司的建模工程师的岗位。

　　3.1 系统建模工程师的主要职责

　　系统建模工程师的日常工作是主要是通过模型仿真对设计方案进行评估，完成“建模-仿真-评估”的迭代。首先，根据项目需要建立模型。然后，进行仿真，收集数据。为了能够反映出设计的正面和负面影响，仿真要涵盖尽可能多的应用环境（测试程序或测试向量）。最后，分析仿真数据，评估设计方案能否满足设计需求、评估模块或者系统设计方案有无缺陷等。

　　系统建模工程师的具体工作方向可以分为架构建模和验证建模两个方向。架构建模评估的是想法；验证建模评估的是具体设计。

　　在架构建模方向，建模工程师的主要输出就是用大量的仿真数据评估设计方案。当设计不满足需求或存在缺陷时时候，架构建模还要被用来验证改进方案能否修正设计缺陷并且不引起更多的问题。在仿真结束后应给出改进方案是否可行的结论，并反馈给方案的制定者（设计方案通常为资深架构师或设计主管共同协商确定）。

　　在验证建模方向的工程师的主要职责是将电路仿真的结果与架构模型和算法模型的仿真结果进行对比，可以判断电路功能是否正确。而仿真的结果要反馈给RTL设计人员，用于检验其RTL设计中存在什么问题。验证方向的建模工程师还会为验证模型和系统搭建软硬件联合验证环境，提供作为激励和收集被测模块响应的软件模型，开发信号交互的驱动。

　　3.2 系统建模工程师的能力

　　为了适应建模工作，系统建模工程师的能力要求与硬件开发工程师和软件开发工程师有很大不同。

　　从技术方面，系统建模工程师需要具备广阔的技术涉猎范围，但是不要求样样精通。除了对于软件设计和硬件设计的技术，系统建模工程师还要了芯片功能的相关知识，比如计算机原理、信号处理和AI等等。快速学习和快速上手能力是系统建模工程师区别于其他岗位最大的不同。

　　从人际交往方面，系统工程师不仅需要较好的人际沟通能力，还需要较强的技术沟通能力。为了获取系统的特性并且反馈模型研究的结果，系统建模工程师需要与硬件和软件开发工程师进行反复的交流。良好的人际沟通能力自然会使这一过程变得更高效。

　　另一方面，硬件工程师和软件工程师的技术语言和体系是完全不同的。前端工程师和后端工程师的观点和想法也会有不同。系统建模工程师要能够以对方熟悉的方式与硬件或软件工程师进行交流，这就是技术沟通能力。技术沟通能力建立在建模工程师对于技术的充分了解的基础上，也建立在建模工程师的同理心和换位思考的角度上。

　　从个人性格方面，系统建模工程师需要对于技术保有单纯的好奇和兴趣。系统建模工程师需要学习很多方面的知识，而且每一个新项目都不是对之前项目的重复。如果没有个性支撑，系统建模工程师也会陷入疲惫。

　　对系统建模工程师真正的挑战在于，如何在没有参考的情况下，确认模型实现和分析是正确的。如果模型有错误或者缺陷，那么会直接导致仿真结果和分析结果乃至决策结果错误。在没有对应硬件系统的时候，系统建模工程师是没有办法对模型进行校准的。系统建模工程师必须要能够根据对设计的理解，设计巧妙的测试程序，验证模型是否正确。要做到这一点，需要建模工程师具有足够的技术积累，并且深入理解被建模的设计。同时，建模工程师要具有缜密的思维和清晰的逻辑。

　　系统建模工程师“站得高，看得远”。系统建模工程师可以学习到设计流程中各个环节的知识，不仅有逻辑设计的技巧，还有物理设计的体系，更有芯片用途的重要背景知识。最终，系统建模工程师是可以将这个系统讲清楚的人。

　　系统建模工程师虽然可能接触很多技术领域，不过没有明确的技术提升路径。如果系统建模工程师不能够主动思考，认为完成建模和验证的工作就够了，那么系统建模工程师就在设计流程中陷入了被动的角色。系统建模工程师的技术提升依赖于工程师自己多想一点。对遇到的有趣现象的刨根问底，才使得系统建模工程师不断夯实技术，提升技术。系统建模工程师可以通过建模来充分理解现有设计以及设计的内在规律，从而自己提出设计优化方案，在设计流程中占据主动。

　　附录：部分公司对于集成电路建模工程师任职要求

　　职位1：RISC-V CPU设计/建模资深工程师

　　岗位职责

　　1.研发高性能RISC-V CPU Core；

　　2.制定/参与RISC-V处理器模块微结构设计规范；

　　3.负责/参与开发RISC-V CPU性能/功耗模拟器、模型和测试集；

　　4.对性能、功耗、面积进行分析和权衡，选取RISC-V CPU优化设计方案；

　　5.负责/参与开发处理器模块的RTL；

　　6.与验证团队协作，验证CPU设计的正确性；

　　7.与物理设计团队协作，实现时序收敛和功耗优化。

　　岗位要求

　　1.计算机科学、计算机工程或电子工程等相关专业学位；

　　2.有以下至少一项经验：计算机体系结构知识；CPU微架构知识；CPU周期精准性能模拟器，如GEM5等；Power management, security等领域知识；

　　3.有工业界处理器研发经验者优先；

　　4.良好的团队合作精神，工作态度积极。

　　职位2：x86系统建模&性能分析工程师

　　岗位职责

　　1.针对CPU、Cache、系统总线、DDR控制器等关键部件构建性能模型；

　　2.仿真、分析现有系统架构的性能瓶颈；

　　3.探索新的架构设计方案、提供架构改进方面和初步性能评估参数；

　　4.搭建系统功能级仿真平台，为固件、驱动开发提供支持。

　　岗位要求

　　1.计算机或电子工程相关专业；

　　2.具有良好的C/C++编程能力；

　　3.对计算机体系结构有较深入的了解，特别是CPU微架构、Cache设计及DDR控制器；

　　4.有计算机系统架构或SoC设计经验者优先；

　　5.有SystemC开发经验者优先；

　　6.熟悉计算机仿真技术者优先，如Bochs，Qemu，GEM5等；

　　7.有RTL设计经验者优先；

　　8.熟悉x86汇编和体系结构这优先。

　　职位3：SoC性能模拟工程师

　　岗位职责

　　1.CPU微架构性能模拟器开发；

　　2.系统级性能模拟器开发；

　　3.基准测试程序性能分析和研究；

　　4.面向微架构的基准测试程序开发。

　　岗位要求

　　1.熟悉CPU微架构；

　　2.了解计算机体系结构；

　　3.了解linux kernel；

　　4.具备一定编译器和指令集知识；

　　5.熟练C/C++以及python开发。

　　职位4：ESL架构师

　　岗位职责

　　1.芯片核心算法到整体架构的建模，ESL仿真平台搭建，应用场景用例构建；

　　2.性能仿真数据分析，大数据自动化到智能化处理；

　　3.基于ESL流程负责完成IP建模、平台构建和仿真，负责完成套片或芯片软硬件调试和性能分析，实现架构探索和验证；

　　4.负责芯片架构ESL需求和端到端计划管理；

　　5.ESL平台仿真速度和指令以易用性持续提升；

　　6.为有竞争力、高质量的芯片架构方案提供可靠依据和数据，能提供优化改进架构方案；

　　7.先进ESL开发流程、方法技术的探索。

　　岗位要求

　　1.具有良好的业务抽象和芯片系统分析能力，能够使用SystemC/C+C/CSystemVerilog等语言已经芯片ESL建模和验证。

　　2.熟练使用C或C++语言。

　　3.熟练使用脚本语言，比如perl、tcl、python等中的一种；

　　4.微电子、通信、计算机等理工类本科及以上学历；

　　5.了解数字电路设计、微机原理；

　　6.善于沟通，具有很好的团队协作能力。