设计指南,用ARM搞个汽车芯片

2019年05月05日 作者:satoll

时隔一年,终于有机会再攒一颗芯片。这一次,是热点中的汽车芯片。

记得两年前,在中国找不出几家做前装汽车芯片的公司。而两年后的今天,突然如雨后春笋般的涌现出十多家,其范围涵盖了辅助驾驶,中控,仪表盘,T-Box,网关,车身控制,电池管理,硬件加解密,激光雷达,毫米波雷达,图像传感器和图像信号处理器等,八仙过海各显神通。

全球范围内,汽车芯片一年销售额大致是$400亿,其中数字芯片$100亿:信息娱乐(中控)芯片约$25亿,均价在$25;MCU约$60亿,30亿片,均价$2;辅助驾驶约$17亿。全球一年大约卖一亿辆车,每辆车平均$100的数字芯片。其中辅助驾驶芯片处于快速增长阶段。汽车芯片的主要供应商,恩智浦,瑞萨数字部分较多,英飞凌,德州仪器模拟部分较多。汽车芯片是仅存的几个利润还不错的市场,技术门槛也并非不可逾越,更不存在绝对的生态闭环。只是量没有消费电子那么大,一年出个几百万片就不错了。在这个领域里,新造车势力方兴未艾,传统造车势力追求差异化,又赶上5G,自动驾驶与人工智能的热点,于是汽车芯片成了继虚拟现实,矿机,NB-IOT,人工智能之后新的投资方向。

上图是一个典型的汽车电子系统框架。这个系统分为几个域,车身,动力总成,底盘,信息娱乐,辅助驾驶,网关和T-Box。每个域有着各自的域控制器,通过车载以太网和Can总线互联。我们就以架构上最复杂的中控和辅助驾驶芯片为例,展开探讨其设计思路与方法。

新一代的中控芯片的架构如下图,主要由处理器,图形处理器,多媒体,图像处理,安全(Security)管理,功能安全(Safety),片上调试和总线等子系统构成。它和通常的应用处理器区别主要在于虚拟化,功能安全,实时性和车规级电气标准。

先说虚拟化。虚拟化其实是从服务器来的概念,为什么汽车也会有这个需求?两点原因:现在的中控芯片有一个趋势,集成仪表盘,降低成本。以前的仪表盘通常是用微控制器做的,图形界面也较简单。而现在的系统越来越炫,甚至需要图形处理器来参与。很自然的,这就使得中控和仪表盘合到单颗芯片内。它们跑的是不同的操作系统,虚拟化能更好的实现软件隔离。当然,有些厂商认为虚拟化还不够,需要靠物理隔离才放心,这是后话,稍后展开。另一个趋势是中控本身需要同时支持多个屏幕,每个屏幕分属于不同的虚拟机和操作系统,这样能简化软件设计,提高软件的可靠性。

虚拟化在硬件上有什么具体要求?这并没有明确定义。可以依靠处理器自带的二阶内存管理单元(s2MMU),实现软件虚拟机;也可以在内存控制器前放一个硬件防火墙MPU,对访问内存的地址进行检查和过滤,不做地址重映射;还可以使用系统内存管理单元SMMU实现完整的硬件虚拟化,这是我们要重点介绍的。

如上图黄色框所示,每个主设备和总线之间,都加了一个SMMU600。为什么每个主设备后都要加?很简单,如果不加,那必然存在安全漏洞,和软件虚拟化无异。那为何不用MPU?MPU的的实现方法,通常是用一个片上内存来存放过滤表项。如果做到4K字节的颗粒度,那4G字节内存就需要1百万项,每项8位,总共1MB的片上内存,这是个不小的成本。另外一个原因是,MPU方案的物理地址空间对软件是不透明的,采用SMMU对上层软件透明,更贴近虚拟化的需求。

当处理器发起一次地址虚实转换请求,MMU会在内部的TLB缓存和Table Walk缓存查找最终页表项和中间表项。如果在内部缓存没找到,那就需要去系统缓存或者内存读取。在最差情况下,每一阶的4层中间表可能都是未命中,4x4+4=20,最终会需要20次内存读取。对于SMMU,情况可能更糟。如上图所示,由于SMMU本身还需引入多级描述符来映射多个页表,最极端情况需要36次的访存才能找到最终页表项。如果所有访问都是这个延迟,显然无法接受。

Arm传统的设计是添加足够大的多级TLB缓存和Table Walk缓存,效果如下:

这是启用2阶地址映射后的实测结果,其各项缓存大小均配置成较大,然后把两个主设备连到接口,进行地址较为随机的访问。可以看到,主设备的5万次访问,在经过SMMU后,产生了近5万次未命中。这意味着访问的平均延迟等于访存延迟,150ns以上。另一方面,处理器开了虚拟机后,它的随机访存效率,和未开虚拟机比,却能做到80%以上,这是为什么呢?答案很简单,处理器内部的MMU,会把中间页表的物理地址继续发到二级或者三级缓存,利用缓存来减少平均延迟。而SMMU就没有这么幸运,在Arm先前的手机处理器参考设计中,并没有系统缓存。这种情况下,即使对于延迟不太敏感的主设备,比如图形处理器,打开虚拟化也会造成性能损失,可能高达9%,这不是一个小数目。

怎么解决这个问题?在Arm服务器以及下一代手机芯片参考设计中,会引入网状结构总线,而不是之前的交叉线结构的一致性总线。网状结构总线的好处,主要是提升了频率和带宽,并且,在提供多核一致性的同时,也可以把系统缓存交给各个主设备使用。不需要缓存的主设备还是可以和以前一样发出非缓存的的数据传输,避免额外占用缓存,引起频繁的缓存替换;同时,SMMU可以把页表和中间页表项放在缓存,从而缩短延迟。

Arm的SMMU600还做了一点改进,可以把TLB缓存贴近各个主设备做布局,在命中的情况下,一个时钟周期就可以完成翻译;同时,把Table Walk缓存放到另一个地方,TLB缓存和Table Walk缓存通过内部总线互联。几个主设备可以同时使用一个Table Walk缓存,减少面积,便于布线的同时,又不失效率。其结构如下图:

如果我们读一下Arm的SMMU3.x协议,会发现它是支持双向页表维护信息广播的,这意味着除了缓存数据一致性外,所有的主设备,只要遵循SMMU3.x协议,可以和处理器同时使用一张页表。在辅助驾驶芯片设计时,如果需要,把重要的加速器加入同一张页表,可以避免软件页表更新操作,进一步提高异构计算的效率。不过就SMMU600而言,它仅仅支持单向的广播,接了SMMU600的主设备,本身的缓存和页表操作并不能广播到处理器,反过来是可以的。

对于当前的汽车芯片,如果没有系统缓存,那如何减少设备虚拟化延迟呢?办法也是有的。汽车的虚拟机应用较为特殊,目前8个虚拟机足够应付所有的分屏和多系统需求,并且一旦分配,运行阶段无需反复删除和生成。我们完全可以利用这点,把二阶段的SMMU页表变大,比如1GB,固定分配给某个虚拟机。这样,设备在进行二阶段地址映射时,只需少数几项TLB表项,就可以做到一直命中,极大降低延迟。需要注意的是,一旦把二阶映射的物理空间分配给某设备,就不能再收回并分给其他设备。不然,多次回收后,就会出现物理地址离散化,无法找到连续的大物理地址了。

SMMU接受的是从主设备发过来的物理地址,那它是怎么来区分虚拟机呢?靠的是同样从主设备发送过来的vmid/streamid。如果主设备本身并不支持虚拟化,那就需要对它进行时分复用,让软件来写入vmid/streamid。当然,这个软件必须运行在hypervisor或者是secure monitor,不然会有安全漏洞。具体的做法,是在虚拟机切换的时候,hypervisor修改寄存器化的vmid/streamid,提供输入给SMMU即可。如果访问时的id和预设的不符,SMMU会报异常给hypervisor。

1 2 3 4 5

相关文章