一文读懂汽车芯片设计!.doc
《一文读懂汽车芯片设计!.doc》由会员分享,可在线阅读,更多相关《一文读懂汽车芯片设计!.doc(21页珍藏版)》请在三一办公上搜索。
1、一文读懂汽车芯片设计!时隔一年,终于有机会再攒一颗芯片。这一次,是热点中的汽车芯片。记得两年前,在中国找不出几家做前装汽车芯片的公司。而两年后的今天,突然如雨后春笋般的涌现出十多家,其范围涵盖了辅助驾驶,中控,仪表盘,T-Box,网关,车身控制,电池管理,硬件加解密,激光雷达,毫米波雷达,图像传感器和图像信号处理器等,八仙过海各显神通。全球范围内,汽车芯片一年销售额大致是400亿刀,其中数字芯片100亿刀:信息娱乐(中控)芯片约25亿刀,均价在25刀;MCU约60亿刀,30亿片,均价2刀;辅助驾驶约17亿刀。全球一年大约卖一亿辆车,每辆车平均100刀的数字芯片。其中辅助驾驶芯片处于快速增长阶段
2、。汽车芯片的主要供应商,恩智浦,瑞萨数字部分较多,英飞凌,德州仪器模拟部分较多。汽车芯片是仅存的几个利润还不错的市场,技术门槛也并非不可逾越,更不存在绝对的生态闭环。只是量没有消费电子那么大,一年出个几百万片就不错了。在这个领域里,新造车势力方兴未艾,传统造车势力追求差异化,又赶上5G,自动驾驶与人工智能的热点,于是汽车芯片成了继虚拟现实,矿机,NB-IOT,人工智能之后新的投资方向。上图是一个典型的汽车电子系统框架。这个系统分为几个域,车身,动力总成,底盘,信息娱乐,辅助驾驶,网关和T-Box。每个域有着各自的域控制器,通过车载以太网和Can总线互联。我们就以架构上最复杂的中控和辅助驾驶芯片
3、为例,展开探讨其设计思路与方法。新一代的中控芯片的架构如下图,主要由处理器,图形处理器,多媒体,图像处理,安全(Security)管理,功能安全(Safety),片上调试和总线等子系统构成。它和通常的应用处理器区别主要在于虚拟化,功能安全,实时性和车规级电气标准。先说虚拟化。虚拟化其实是从服务器来的概念,为什么汽车也会有这个需求?两点原因:现在的中控芯片有一个趋势,集成仪表盘,降低成本。以前的仪表盘通常是用微控制器做的,图形界面也较简单。而现在的系统越来越炫,甚至需要图形处理器来参与。很自然的,这就使得中控和仪表盘合到单颗芯片内。它们跑的是不同的操作系统,虚拟化能更好的实现软件隔离。当然,有些
4、厂商认为虚拟化还不够,需要靠物理隔离才放心,这是后话,稍后展开。另一个趋势是中控本身需要同时支持多个屏幕,每个屏幕分属于不同的虚拟机和操作系统,这样能简化软件设计,提高软件的可靠性。虚拟化在硬件上有什么具体要求?这并没有明确定义。可以依靠处理器自带的二阶内存管理单元(s2MMU),实现软件虚拟机;也可以在内存控制器前放一个硬件防火墙,对访问内存的地址进行检查和过滤,不做地址重映射;还可以使用系统内存管理单元SMMU实现完整的硬件虚拟化,这是我们要重点介绍的。如上图黄色框所示,每个主设备和总线之间,都加了一个MMU600。为什么每个主设备后都要加?很简单,如果不加,那必然存在安全漏洞,和软件虚拟
5、化无异。那为何不用防火墙?防火墙的的实现方法,通常是用一个片上内存来存放过滤表项。如果做到4K字节的颗粒度,那4G字节内存就需要1百万项,每项8位,总共1MB的片上内存,这是个不小的成本。另外一个原因是,防火墙方案的物理地址空间对软件是不透明的,采用系统内存管理器SMMU600对上层软件透明,更贴近虚拟化的需求。当处理器发起一次地址虚实转换请求,内存管理单元会在内部的TLB缓存和Table Walk缓存查找最终页表项和中间表项。如果在内部缓存没找到,那就需要去系统缓存或者内存读取。在最差情况下,每一阶的4层中间表可能都是未命中,4x4+4=20,最终会需要20次内存读取。对于系统内存管理器,情
6、况可能更糟。如上图所示,由于SMMU本身还需引入多级描述符来映射多个页表,最极端情况需要36次的访存才能找到最终页表项。如果所有访问都是这个延迟,显然无法接受。Arm传统的设计是添加足够大的多级TLB缓存和table walk缓存,效果如下:这是启用2阶地址映射后的实测结果,其各项缓存大小均配置成较大,然后把两个主设备连到接口,进行地址较为随机的访问。可以看到,主设备的5万次访问,在经过SMMU后,产生了近5万次未命中。这意味着访问的平均延迟等于访存延迟,150ns以上。另一方面,处理器开了虚拟机后,它的随机访存效率,和未开虚拟机比,却能做到80%以上,这是为什么呢?答案很简单,处理器内部的M
7、MU,会把中间页表的物理地址继续发到二级或者三级缓存,利用缓存来减少平均延迟。而SMMU就没有这么幸运,在Arm先前的手机处理器参考设计中,并没有系统缓存。这种情况下,即使对于延迟不太敏感的主设备,比如图形处理器,打开虚拟化也会造成性能损失,可能高达9%,这不是一个小数目。怎么解决这个问题?在Arm服务器以及下一代手机芯片参考设计中,会引入网状结构总线,而不是之前的crossbar结构的一致性总线。网状结构总线的好处,主要是提升了频率和带宽,并且,在提供多核一致性的同时,也可以把系统缓存交给各个主设备使用。不需要缓存的主设备还是可以和以前一样发出非缓存的的数据传输,避免额外占用缓存,引起频繁的
8、缓存替换;同时,SMMU可以把页表和中间页表项放在缓存,从而缩短延迟。Arm的SMMU600还做了一点改进,可以把TLB缓存贴近各个主设备做布局,在命中的情况下,一个时钟周期就可以完成翻译;同时,把table walk缓存放到另一个地方,TLB缓存和table walk缓存通过内部总线互联。几个主设备可以同时使用一个table walk缓存,减少面积,便于布线的同时,又不失效率。其结构如下图:如果我们读一下Arm的SMMU3.x协议,会发现它是支持双向页表维护信息广播的,这意味着除了缓存数据一致性外,所有的主设备,只要遵循SMMU3.x协议,可以和处理器同时使用一张页表。在辅助驾驶芯片设计时,
9、如果需要,把重要的加速器加入同一张页表,可以避免软件页表更新操作,进一步提高异构计算的效率。不过就SMU600而言,它仅仅支持单向的广播,接了SMU600的主设备,本身的缓存和页表操作并不能广播到处理器,反过来是可以的。对于当前的汽车芯片,如果没有系统缓存,那如何减少设备虚拟化延迟呢?办法也是有的。汽车的虚拟机应用较为特殊,目前8个虚拟机足够应付所有的分屏和多系统需求,并且一旦分配,运行阶段无需反复删除和生成。我们完全可以利用这点,把二阶段的SMMU页表变大,比如1GB,固定分配给某个虚拟机。这样,设备在进行二阶段地址映射时,只需少数几项TLB表项,就可以做到一直命中,极大降低延迟。需要注意的
10、是,一旦把二阶映射的物理空间分配给某设备,就不能再收回并分给其他设备。不然,多次回收后,就会出现物理地址离散化,无法找到连续的大物理地址了。SMMU接受的是从主设备发过来的物理地址,那它是怎么来区分虚拟机呢?靠的是同样从主设备发送过来的vmid/streamid。如果主设备本身并不支持虚拟化,那就需要对它进行时分复用,让软件来写入vmid/streamid。当然,这个软件必须运行在hypervisor或者是secure monitor,不然会有安全漏洞。具体的做法,是在虚拟机切换的时候,hypervisor修改寄存器化的vmid/streamid,提供输入给SMMU即可。如果访问时的id和预设
11、的不符,SMMU会报异常给hypervisor。如果主设备要实现硬件的方式支持虚拟化,那本身需要根据多组寄存器设置,主动发出不同的vmid/streamid。为了对软件兼容,可以把不同组按照4KB边界分开,这样在二阶地址映射时,可以让相同的实地址访问不同组的寄存器,而对驱动透明。同时,对于内部的资源也要做区分,不能让数据互相影响。如果用到缓存,那缓存还必须对vmid敏感,相同地址不同vmid的情况,必须识别为未命中。如果主设备本身不支持虚拟化,并且本身特别复杂,那还需要定制驱动。以Arm的图形处理器为例,到目前为止,硬件上还没有正式支持虚拟化,如果软件要支持,可能会有以下几种方案:假设我们用的
12、Hypervisor是Xen,它运行于Arm处理器的EL2,虚拟机运行于EL0/1。正常的图形处理器驱动会分成用户空间与核心空间两部分。要实现虚拟化,时分复用图形处理器,Xen上本身不可能跑驱动,因为目前驱动只支持Linux。所以就只能让虚拟机来跑原先的驱动,而没有办法在hypervisor上再运行一个驱动来进行访问控制。同时,重映射图形处理器在CPU上的二阶段地址,让寄存器访问和数据通路处于穿透的模式,不引起异常,提高效率。相应的,让虚拟机直接访问寄存器,那访问控制就实现不了了。为了实现多虚拟机的调度,我们可以在hypervisor里面实现一个调度器,并且在核心态的驱动部分开放接口,让hyp
13、ervisor可以主动调度。示意图如下:这个实现的优点很明显,改动较少,实现简单,无论是Xen和KVM都可以适配。缺点是主动权并不掌握在hypervisor,如果某个虚拟机上渲染任务过于繁重,一直不把控制权交给调度器,那只有强制重启。另一个明显的缺点是,无法在图形处理器同时运行两个虚拟机上的任务。这就需要另一种虚拟机的实现方式,如下图:在这种实现下,虚拟机里只跑驱动的用户空间,所有涉及核心空间的调用全都扔到Hypervisor。这要求hypervisor本身是Linux,只有KVM符合这个要求。Arm的Mali图形处理器,硬件上是支持指定某个渲染核心跑特定任务的,也就是可以把某个虚拟机的任务运
14、行在特定渲染核心的。这样,如果有实时性的操纵系统要跑,比如仪表盘,可以保留出一个核来,不被其他虚拟机抢占,来实现一定程度的QoS。此时,图形处理器是真正同时跑两个虚拟机任务的,而不是时分复用。至于输出的frame buffer,不同的任务是可以放到不同物理地址的,只是没法区分SteamID,没法做隔离。Arm支持硬件虚拟化的图形处理器估计还要一年才会出来。具体到细节,虚拟化除了需要寄存器分组,缓存对vmid敏感之外,通用的一些单元也需要支持分组。关于虚拟机的效率,还有两点需要注意:Arm现有的中断控制器GIC600,受限于GICv3.x协议,是没有办法绕过hypervisor,直接把虚拟中断送
15、到Guest OS的。外部中断送进来,还是得经由hypervisor权限设置寄存器,产生一个虚拟中断到Guest OS。中断直接送到Guest OS要到GICv4才会改进。Armv8.1及之后的CPU,都支持一个叫VHE的机制,可以加速2型虚拟机的切换。具体原理是,KVM等2型虚拟机,Hypervisor就在Linux核心里面,而Linux需要完整的2阶3/4层页表。另外一方面,Armv8.1之前的处理器EL2没有对应的页表。如果没有VHE,那这个Hypervisor必须把一部分驻留在EL2做高权限操作,而Host Linux还是运行在EL1。这样,很多操作需要从EL1陷入EL2,改完再回到E
16、L1的Linux核心,多了一层跳转。有了VHE,那么Host Linux核心直接运行在EL2,可以操作EL1的4层页表的页表寄存器,软件上不用做修改。硬件上,这些访问会被重定向到EL2,以保证权限。对于1型虚拟机,比如Xen,这个改动没有影响。这里我们要提一下QNX的虚拟机,它是1型虚拟机。QNX是目前唯一一个能达到Asil-D等级的操作系统(包含Hypervisor)。如果需要实现Asil-D级别的系统,必须把现有的软件从Linux系统移植到QNX。所幸的是,QNX也是符合Posix标准的,尤其是图形处理器的驱动,移植起来会省事一些。QNX不是所有的模块都是Asil-D级,移植过去的驱动,其
17、实是没有安全等级的。QNX依靠Asil-D级的核心软件模块和Hypervisor,保证99%以上的失效覆盖率。如果子模块出了问题,那只能重启子模块。前面说到,有些厂商认为虚拟化还不够,有些场景要物理隔离。虚拟化的时候,硬件资源还是共享的,只不过对软件是透明。这样其实并不能完全防止硬件的冲突和保证优先级。请注意,硬件隔离是separation,而不是分区partition,Partition是用MPU来做的。在中控的系统框架图内,我们把采用物理隔离的红色部分单独列出来,如下图:此时的处理器A55和图形处理器G31,独立于作为信息娱乐域的处理器A76/A55和图形处理器G76之外,拥有自己的电源,
18、时钟和电压。作为优化,红色部分可以和其余的处理器用一致性总线连接起来,在不作为仪表盘应用的时候,作为SMP的一部分来使用。而需要隔离的时候,用多路选择连接到NoC或者内存控制器。这样既节省了面积,又实现了隔离。同样的,图形处理器也有物理隔离的需求。实现其实并不复杂,比支持硬件虚拟化要直接,如下图:由于图形处理器面积最大的是渲染核心SC,这部分不动。其余的硬件模块,每组核都复制一份,组和组之间用内部总线ASN互联。当拆成多个图形处理器的时候,每个冗余模块分别控制自己的资源。此时,每组GPU需要独立运行一个驱动。而把所有资源融合运行的时候,冗余的部分自动关闭,由一个模块集中调度。此时,某些公用资源
19、可能会遇到性能瓶颈,但汽车通常只会要求物理隔离两个组,分别给仪表盘和信息娱乐,并且仪表盘所需资源较少,融合的时候,可以启用信息娱乐的共享单元,从而避免瓶颈。对于系统中其余的主设备,也可以利用类似的设计思路来实现隔离。有了同时支持虚拟化和硬件隔离的图形处理器,我们的中控芯片构架会有如下改动:此时图形处理器的物理隔离和硬件虚拟化可以同时启用,跑多份驱动,满足前文的需求。至此,虚拟化和隔离结束,开始讨论车规。目前我们说的车规分两个,功能安全和电气标准。前者由ISO26262定义,后者由AEC-Q100定义。功能安全在芯片上的设计原则是要尽可能多的找出芯片上的失效场景并纠正。失效又分为系统和随机两种,
20、前者依靠设计时的流程规范来保证,后者依赖于芯片设计上采取的种种失效探测机制来保证。我们在这主要谈后者。简单来说,芯片的失效率,是基于单个晶体管在某个工艺节点的失效概率,推导出片上逻辑或者内存的失效概率。面积越大,晶体管越多,相应的失效率越大。ISO26262把安全等级做了划分,常见的有ASIL-B和ASIL-D级。ASIL-B要求芯片能够覆盖90%的单点失效场景,而ASIL-D则是99%。这其实是个非常高的要求。一个晶体管的失效概率虽低,可是通常一个复杂芯片是上亿个晶体管组成的,如果不采取任何措施,那任何一点的错误都可能造成功能失效,失效率很高。ISO26262手册第五篇的附件D,详细描述了硬
21、件失效的探测手段。在这部分,硬件系统被分为几个模块:输入端有传感器,连接件,中继,数模接口;处理部分包含处理单元,各类内存闪存。系统层面有总线,电源和时钟。系统框架如下图:针对每一单元,ISO26262手册定义了一些方法,来检测这些单元是否失效,并给出每一种方法的可靠度。比如传输线,可以有校验码,超时,计数器,发送测试向量等。再比如处理单元,可以使用软硬件自检,冗余加比较,额外硬件模块监测等方法。这些方法并不能简单的应用于芯片功能安全设计。那芯片上怎么办?我们采用自底向上的方法,先从晶体管开始分析,再到IP模块级,然后到芯片系统级,再讨论几个典型场景,最后自顶向下分析。在芯片的随机错误中,有一
22、类是永久错误,比如逻辑或者片上内存的某一位一直粘在0或者1,或者干脆短路及断路。对于这一类错误,在芯片封测的时候,我们可以使用边界扫描和MBIST来发现坏掉的晶体管。这样,问题就转换为怎样提高DFT的覆盖率。这一块,业界已经有成熟的方法了。仅仅有出厂测试是不够的,晶体管会在使用过程中慢慢老化损坏。因此,我们需要在每次开机的时候都进行自检,提前发现问题,减少在系统运行状态下出错的可能。此时,我们需要使用LBIST和MBIST。其原理和出厂测试很像,也是利用扫描链,不同的是芯片里需要LBIST/MBIST控制器,用来运行测试向量和模板。自然,这会引入额外的成本。覆盖率越高,成本相应越大。有了LBI
23、ST/MBIST也还不够,我们需要在晶体管失效发生后几个时钟周期就探测到错误,而不是开机时候发现。对于逻辑来说,为了做到这点,最直接的方法莫过于采用冗余设计,也就是把逻辑复制一份,然后用硬件比较器比较输出。通常这被称为锁步设计(Lock-Step)。理论上,对于有限状态机,只要输入一致,时钟周期一致,输出一定一致。通常数字部分不存在真随机单元,哪怕是缓存替换算法,也是伪随机的,所以上述条件可以满足。冗余的结果是逻辑面积增加一倍,比较器也会引入一些额外的面积开销和时序影响。这么简单就实现了功能安全?并没有,有几个问题需要解决:第一个问题是,比较器到底比哪些信号?以处理器为例,如果我们只是在对总线
24、的接口上增加比较器,芯片内部的很多模块,比如写缓冲,并不能在较短且确定的时间内把影响传递到对外接口,被比较器发现。此时,处理器可能是处于失效状态而并没有被探测出来。那我们就不能说当前冗余机制能覆盖此类失效。为此,我们需要把比较器连到内部子模块接口处,并且分析是不是能在较短时间内看到影响。这需要在设计阶段就考虑,具体做法如下图:对于任何一个寄存器,一定可以找到影响它的组合逻辑和上一级寄存器。在这条通路上任何一位出了问题,那么在一个时钟周期后,我们就可以看到寄存器输出与其冗余的模块产生不一致。把这个节点记为1,然后再以1的输入寄存器为新起点,找到节点2。依次类推,我们可以往前找出一条没有循环的通路
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 读懂 汽车 芯片 设计

链接地址:https://www.31ppt.com/p-4914602.html