LIN验证框架：一种新途径

汽车半导体行业目前所处的时代，是试图利用机电一体化系统替代复杂的机械互联的时代。为了简化布线设计，也为了有效处理汽车各系统之间的通信流程，就设计了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帧

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

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

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


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

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


图3：SoC上的LIN

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

A.低功耗子系统故障

系统中会有多个LIN实例。其中一个场景是整个SoC都处于省电模式，LIN计时仍在继续，因此它可以接收外界的数据包，并在帧接收后中断时唤醒系统。其中一个LIN实例就是无法在这种情况下唤醒系统。
计时控制中也出现了问题。系统进入低功耗模式时，无法正确启动LIN计时来在低功耗状态下接收数据包。

B.LIN-DMA握手问题

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

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

C.车载LIN物理层问题

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


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

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

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

随机化——找出极端案例

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

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


图5：随机化的基本流程

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

·输入时钟源选择随机化
·输入时钟频率随机化
·输出波特随机化
·LIN参数随机化
·LIN实例随机化
·IO pad mux随机化

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

菊花链检查

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

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


图6：随机化的基本流程

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

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

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

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

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


图7：38.4Kbps时的正确数据

我们认真观察可以发现，传入流中的停止位比1位宽稍宽一些。
现在，我们可以看到9600bps的波形。

故障场景：


图8：9.6Kbps时丢失的数据

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

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

结论与未来工作

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

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