技术中心
 
 

LIN验证框架:一种新途径

   日期:2015-09-29    
核心提示:汽车半导体行业目前所处的时代,是试图利用机电一体化系统替代复杂的机械互联的时代。为了简化布线设计,也为了有效处理汽车各系统之间的通信流程,就设计了LIN(局域互联网)总线协议,广泛应用于门锁、车镜、雨水传感器、动力总成、中央电子控制单元(ECU)等诸多应用,即使在超高温条件下也可正常运作。

汽车半导体行业目前所处的时代,是试图利用机电一体化系统替代复杂的机械互联的时代。为了简化布线设计,也为了有效处理汽车各系统之间的通信流程,就设计了LIN(局域互联网)总线协议,广泛应用于门锁、车镜、雨水传感器、动力总成、中央电子控制单元(ECU)等诸多应用,即使在超高温条件下也可正常运作。

设计中一个小小的缺陷都有可能是致命的!因此应适时进行可靠稳定的检查,验证系统的正确性和稳健性。有许多实际场景无法在SoC上轻松再现。例如,发动机周围温度过高,就可能导致设置或保持时间不正确,产生错误采样。这会造成数据损坏,导致故障。同样,车内的电磁或环境噪声会触发某个比特的变换,这也可能是致命的。对于进行芯片后验证的工程师,再现这些场景并在在芯上进行恰当处理是一项充满挑战的工作。

本文介绍了一些LIN设计问题,这些问题出现在芯片上,设置复杂。本文详细阐述了多个由于完整性或架构失误而出现的系统级问题,例如,LIN数据通过DMA传输后,SoC无法进入低功耗模式。本文还重点介绍了LIN的低功耗模式行为,其设计也有望改进。

简介

LIN作为一个低成本系统,由汽车制造商联合设计,可以替代传感器、执行器和开关等应用(在这些应用中速度并不是限制因素)的高速总线,如CAN(控制局域网)。

LIN协议是一种双线广播串行网络,网络中信息由主机进行初始化。主机决定何时将哪个帧传输至总线。LIN帧头具有以下域:

·同步间隔

·同步字节

·ID字节

·数据字节

·校验和字节

模拟错误场景

由于温度变化、干扰等原因,电子系统的噪音噪声无法避免。因此,必须在芯片上彻底验证总线协议的错误处理能力。然而,在实验室中可靠地生成所有的错误场景是一项棘手的工作。通常,SoC不提供任何生成奇偶错误、成帧错误等的方法。为了避免这个限制,我们可以采用函数发生器(FG)等外部设备强制生成错误。通过FG,我们可以操纵LIN帧头,并生成包含所需错误的错误帧。

FG可以用于生成具有以下错误的LIN帧:

·同步域错误

·同步间隔符错误

·ID奇偶错误

·校验和错误

·成帧错误

如果同步域不一致,即报告同步域错误;如果间隔符域过短(小于1位时间),即出现同步间隔符错误;帧头奇偶错误导致ID奇偶错误;如果接收的校验和与预期校验和不符,表示出现校验和错误;无效的结束位会导致成帧错误。多数错误的报告是由于其中一个域中的一个或多个比特变换,如LIN帧的间隔、同步、ID、数据或校验和。

图1是利用FG生成的没有错误的LIN帧。该帧清楚地显示了间隔域、同步域、ID域、数据域及校验和域。ID域的正确解码为0x01,数据域为0x55,校验和为 0xE8。

 

图1:利用函数发生器生成的LIN帧

图1:利用函数发生器生成的LIN帧

由于LIN是一个慢速协议(最大运行速度为20kbps),而且生成错误只涉及到1个位域变换,因此我们可以利用FG轻松复制此类错误场景。

系统级问题——在SoC中最为常见

当今,半导体行业正在生成一个十分复杂的系统,芯片后活动也成为了及其复杂的工作。我们无法想象LIN作为一个独立IP存在于这个系统中。可以通过多个IP时钟源进行计时,并产生大量的波特。在SoC中,LIN可以与DMA、INTC、低功耗子系统等其他多个控制器进行连接,完成特定工作。因此,问题会在任何地方随机出现。

 

图2:利用函数发生器生成的具有奇偶错误的LIN帧

图2:利用函数发生器生成的具有奇偶错误的LIN帧

图2显示的LIN帧含有FG带来的ID奇偶错误。我们可以清晰地看到,尽管检测到的数据正确,为0x55,但由于接收的ID和奇偶不符,因此对ID报错。该错误是由于ID中的一个比特域或两个奇偶域的任意一个域发生了交换。此处是由于改变了正确帧中的一个奇偶位。同样,我们可以通过函数发生器生成包含其他错误的帧。

 

图3:SoC上的LIN

图3:SoC上的LIN

在芯片前模拟环境中,一些实际场景无法在软件模式中复制,许多极端案例可能会被遗漏。例如,电路局部温度升高会导致不必要的锁存器延迟,从而造成整个系统瘫痪。芯片上常出现以下系统级问题:

A.低功耗子系统故障

系统中会有多个LIN实例。其中一个场景是整个SoC都处于省电模式,LIN计时仍在继续,因此它可以接收外界的数据包,并在帧接收后中断时唤醒系统。其中一个LIN实例就是无法在这种情况下唤醒系统。

计时控制中也出现了问题。系统进入低功耗模式时,无法正确启动LIN计时来在低功耗状态下接收数据包。

B.LIN-DMA握手问题

如果一些数据要从存储器传输至另一个存储器,或者从外围设备传输至存储器,或者从存储器传输至外围设备,此时DMA在系统中用于分流内核。

低功耗子系统需要在进入低功耗模式之前解除信号。在DMA传输完成后,信号不会解除,这样系统就不会进入低功耗模式。

这个问题的根本原因在芯片上,在芯片上我们发现DMA传输完成后FIFO标志信号为空,表明LIN需要更多数据,因而阻止整个系统进入低功耗模式。

C.车载LIN物理层问题

LIN是单线协议,它检测“传输开始”,作为其数据线上1至0的切换点。

 

图4:收发器前后的LIN帧探测

图4:收发器前后的LIN帧探测

车载LIN物理层收发器之后的总线上未检测出数据,但在接收器之前的范围内数据正常显示。

在这个问题上,车载LIN物理层采用了强大的下拉电阻器,保持数据线的低压状态。因此LIN无法检测“传输开始”,从而造成无通信。为了克服这个问题,建议在车上使用上拉电阻。

随机化——找出极端案例

随机化是在芯片后验证工程师中非常流行的术语。随着技术从90nm发展至60nm、45nm、28nm直到20nm等,设计的复杂性也在成倍增长。因此,设计缺陷会出现在各个地方,可能是逻辑数字错误、集成问题甚至是由于操作环境的变化而造成的问题,如流程(P)、电压(V)、温度(T)或者频率(F)的变化。因此,在这个充满挑战的环境中,利用定向测试用例解决设计问题并不是一个聪明的解决方案。

那么,解决方案是什么?解决方案在于随机化的过程中。尽可能多的地实现随机化,并让测试用例运行多个小时,给系统增压。如果系统崩溃,就将问题缩小到根本原因的层面上;如果系统安然无恙,说明设计相对稳定!

 

图5:随机化的基本流程

图5:随机化的基本流程

对于LIN而言,随机化可以在各个层面实现:

·输入时钟源选择随机化

·输入时钟频率随机化

·输出波特随机化

·LIN参数随机化

·LIN实例随机化

·IO pad mux随机化

所有这些随机测试的主要意图就是,在参数范围内给系统增压,直至其挂机或崩溃。

菊花链检查

SoC中会有许多LIN的实例,多达20例甚至更多。验证众多实例的所有功能是一项繁琐而费时的工作。为了验证众多实例,LIN协议可以以菊花链的方式运行,不仅可以节省验证工程师的时间,还可以在LIN帧遍历众多实例之时检查数据完整性。

图3介绍了不同LIN实例的菊花链检查。由于LIN是一个单线协议,所有的LIN收发板都可以连接至一个公共线上。第一对实例可以配置为主从对。第二个实例完成数据接收后,可以配置为将接收的数据传输给第三个实例,也是主从对配置。不断重复这个程序,直至数据被最后一个用例接收。这时,数据就可以与初始数据进行比较。

 

图6:随机化的基本流程

图6:随机化的基本流程

LIN/UART应用代码要考虑的问题

LIN/UART不能在超过9600bps的特定设置下运行。

其中一个UART用例是接收来自个人电脑(CP)COM端口的数据。有文本文件从PC端通过超级终端发送。UART按字符接收文本,并再按字符将其发回至PC的COM端口。发送的整个文本文件在超级终端打印出来。超级终端波特率和UART波特率均被设置为同样的值。

如果我们使用的波特率高于192000,就会打印正确的文本。然而,如果波特率低于或等于19200,文本文件的一些字符就被遗漏。随着我们进一步降低波特率,接收的文本就会严重混乱。

黄色波形是从PC中接收(在控制板的Rx引脚取样)。绿色波形是从UART发回至PC(在控制板的Tx引脚取样)。

通过场景:

 

图7:38.4Kbps时的正确数据

图7:38.4Kbps时的正确数据

我们认真观察可以发现,传入流中的停止位比1位宽稍宽一些。

现在,我们可以看到9600bps的波形。

故障场景:

 

图8:9.6Kbps时丢失的数据

图8:9.6Kbps时丢失的数据

就PC一方而言,如黄色波形所示,文本文件包括正确接收的“This”。然而,Tx引脚取样的数据表明,遗漏了字符“h”,而其他字符(“T”、“i”、“s”)均传输成功。

在应用代码方面,比特写操作的状态位会被清除,同时也会在无意间清除其他状态位。速度较高时,在软件清除状态位时已经从控制板上传输了数据,因此没有发现问题,但速度较低时,状态位在数据传输前就被清除,因此出现了这个问题。

结论与未来工作

上述分析及案例研究表明,除了正常的芯片上独立LIN IP验证之外,错误场景及系统级验证也至关重要,可以帮助我们生成没有设计缺陷的SoC。我们无法否认我们需要付出极大的努力,生成错误场景条件并捕获系统级设计问题,但这可以大大帮助半导体行业提供更健康的芯片,从而降低成本。

我们的进一步建议是以最高温度、最低电压进行芯片验证,利用较慢的矩阵槽捕捉设置/保持问题。另一建议是同时通过不同的内核运行不同的LIN实例,更好地给系统增压。

 

 

 

 
标签: LIN 汽车 通信协议
  
  
  
  
 
更多>同类技术
 
全年征稿 / 资讯合作
 
推荐图文
推荐技术
可能喜欢