LIN validation frame-work: A novel approach
Amit Kumar Sinha, Chetan Anand Freescale Semiconductor, India
Saurabh Gupt Freescale Semiconductor, India
Abstract—Automotive semiconductor industry is passing
through an era where it is pushing the complex mechanical interconnects to be replaced by the mechatronical system. To simplify the wiring design and to handle the communication process effectively between various systems in automobiles, LIN (Local Interconnect Network) bus protocol has been designed. It is widely used in numerous applications like door locks, mirrors, rain sensors, powertrain, central ECU, etc even at very high temperature.单板
层积材 Small bug in its design might be fatal! So there should be reliable and stable checks in place to validate the correctness and robustness of the design. There are many real life scenarios which cannot be easily reproducible on SOC. For example, temperature around engine is so high that set-up or hold time violations may occur causing improper sampling. It could result in data corruption which may cause hazardous situations. Similarly electromagnetic or environmental noise in car could toggle a part
icular bit which could again be fatal. Reproducing such scenarios and handling it properly on silicon has been a very challenging task for post silicon validation engineers.
This paper describes some of the LIN design issues which were found on silicon with a truly complex set-up. It elaborates on some system level issues being detected because of integration or architectural SOC was not able to enter low power mode after the LIN data transfer through DMA. It also highlights low power mode behavior of LIN where design improvements are highly expected.
Keywords—LIN, automotive, SOC architecture, communication protocol, bit flipping, error scenarios, signal integrity, low power modes
I.I NTRODUCTION
LIN was designed by vehicle manufacturers consortium as a low cost system which could replace high speed bus like CAN(Control Area Network) in the applications where speed is not the limiting sensors, actuators and switches.
LIN protocol is a 2 wire broadcast serial network in which messages are initiated by the master. The
master decides when and which frame shall be transferred on the bus. LIN header has following fields : ∙Sync Break
∙Sync Byte
∙Checksum Byte
This paper highlights the post-silicon validation strategy which targets the bugs missed either in presilicon verification or in emulation environment. It also describes some critical bug- findings and its analysis. The paper is organized in 7 sections. Section II talks about the error scenario replication on silicon which could occur due to electromagnetic noise or high temperature operating conditions in real life. Section III explains the system level issues coming in LIN. Section IV highlights the random and stress scenario used to hit the corner cases. Section V describes the use-case of daisy-chain wherein multiple LIN instances are transferring data from one node to another. Section VI focuses on application code issues faced by the customer and its analysis in lab. Section VII concludes and summarizes the paper.
II.SIMULATING ERROR SCENARIO Noise in electronic system is inevitable due to temperature variation, interference etc. Therefore, error handling capability of a bus protocol must be thoroughly validated on silicon. However, generating all the error scenarios reliably in the lab is a tricky task. SoCs, generally, do not provide any method to generate these parity error, framing error etc. To get around this limitation, errors can be introduced forcibly using some external equipment like function generator (FG). Through FG, we can manipulate the LIN header and produce an erroneous frame with the desired error. FG could be used to generate a LIN frame having following errors:
2014 IEEE International Conference on Vehicular Electronics and Safety (ICVES) December 16-17, 2014. Hyderabad, India
桥梁
钢模∙S ync Field Error
∙Sync Delimiter Error
∙ID Parity Error
∙Checksum Error
∙Framing Error
Sync Field Error is reported when there is inconsistency in sync field. Sync Delimiter Error occurs when the delimiter field is too short (less than 1 bit time). Wrong parity in header results in ID Parity Error. Checksum Error is indicated when the received checksum does not match expected checksum and an invalid stop bit results in Framing Error. Most of these errors are reported due to toggling of one or many bits in one of the fields, i.e. break, synch, ID, data or checksum, of LIN Frame. Figure 1 shows a LIN frame, having no errors,
generated using FG. This frame clearly shows break field, synch field, ID field, data field and checksum field. ID field is correctly decoded as 0x01, data field as 0x55 and checksum as 0xE8.
Figure 1: LIN Frame using Function Generator
Figure 2 shows a LIN frame with ID parity error introduced by FG. It can be easily noted that although the data detected is correct as 0x55 but an error is reported in ID due to mismatch in ID and parity received. This error can be introduced by toggling a bit field in ID or any of the two parity fields. Here, it is done by changing a parity bit in the correct frame. Similarly, frames with other errors can be generated using function generator.
Figure 2: LIN Frame, with parity error, using Function
Generator
These types of error scenarios are easy to produce using FG because LIN is a slow protocol (working at 20kbps max) and introducing an error involve toggling of 1 bit field only.
III.SYSTEM LEVEL ISSUES- MOST PREVALENT
IN SOC
In recent times semiconductor industry is producing such a complex system that post silicon activities have become immensely complicated effort. We can’t imagine LIN as a standalone IP in such a system. There could be multiple of IP clock sources through which it could be clocked and generate huge range of baud. In the SOC it could be interfacing with various other controllers like DMA, INTC, Low power subsystem etc to achieve a particular task. So, the problem could occur anywhere randomly.
Figure 3: LIN in SOC
Many of the corner-cases might get skipped in
presilicon simulation environment where some real life scenarios cannot be replicated in software model. For example, a local temperature rise in the circuit could cause unnecessary latch delay resulting in complete system failure. Following system level issues are usually found on silicon:
A.Low power subsytem failure
There could be multiple LIN instances in system. In one scenario when the complete SOC was in power-down mode, LIN clocking was still up so that it could receive data packet from the outside world and wake the system up with its interrupt after frame reception. One of the LIN instance was unable to wake-up the system in this situation.
Problem was found in the clocking control. When the system was going in lower power mode it was not properly enabling the LIN clock to receive the data packet in the low power state.
B.LIN-DMA handshake issue
DMA is used in the system to offload the core when some data transfer is expected from memory to memory or peripheral to memory and vice versa.
供氧器Low power subsystem expects a signal to be de-asserted before entering into low power mode. After completion of DMA transfer that signal was not getting de-asserted so the system was not entering low power mode.
This issue was root-caused on silicon where it was found that FIFO empty flag was set after DMA transfer completion which in turn suggesting the LIN to expect some more data and hence, gating the whole system from low power mode entry.
C.On board LIN PHY issue
LIN is single wire protocol which detects “start of transfer” as a transition from 1 to 0 on its data line.
Figure 4: LIN frame probing before and after transceiver
On board, after LIN transceiver/phy, there was no data detected on its bus but it was properly visible on scope before the transceiver.
In this issue, LIN phy on the board was using a strong pull-down resistor keeping the data line always low. So LIN was never able to detect “start of transfer”
resulting in no communication. To overcome the issue, pull-up resistance on board was recommended.
IV.R ANDOMIZATION-T O FIND OUT THE CORNER CASE
表达
载体构建
Randomization is a very popular term among post silicon validation engineers. As the technology is moving from 90 mm to 60 mm to 45 mm to 28 mm to 20mm and further, complexity of the design is increasing multiple fold. So, a bug might come from anywhere in the design. It could be logical digital bug, it could be an integration issue or it could even come because of varying operating variation in Process(P), Voltage(V), Temperature(T) or Frequency(F). So, targeting design issues with directed test-cases could not be a smart solution in such a challenging environment.
What is the solution then? Solution lies in the process of randomization. Randomize as much as you can and let the test-cases running for multiple hours to stress the system. If it fails then narrow-down the problem to
a level where it could be root-caused and if it passes,
design is relatively stable!
Figure 5: Basic flow of randomization
For LIN, randomization can be done at various levels: ∙Input clock source selection randomization
∙Input clock frequency randomization
∙Output baud randomization
∙LIN parameters randomization
∙LIN instances randomization
∙IO pad mux randomization
Through all this randomization, main intent is to stress the system within spec to a level where it should
hang/fail.
V.DAISY CHAIN CHECK
In a SoC, there can be n number of instances of LIN, which may go up to 20 or even more. Validation of all functionalities of these many numbers of instances is quite a tedious and time consuming job. In order to validate a large number of instances, LIN protocol can be run in daisy chain fashion. It would not only save time of the validation engineer but will also check data integrity when the LIN frame has traversed through a number of instances.
Figure 3 describes the daisy chain check of different LIN instances. Since, LIN is a single wire protocol all the LIN transmit-receive pads can be connected to a common wire. First pair of instances can be configured as master-slave pair. After second instance completes data reception, it can be configured to transmit received data to third instance, which are configured as master-slave pair. This procedure is repeated till the data is received by the last instance. The data can now be compared with the initial data.
Figure 6: Basic flow of randomization
VI.L IN/UART APPLICATION CODE CONSIDERATION
ISSUE
LIN/UART was not working in a particular setup beyond 9600 bps.
One of the UART instance was configured to receive data from COM port of PC. From PC’s end there was a text file being sent through hyper terminal. The UART receives text character by character and send it back to COM port of PC again character by character. The whole text file which was sent is printed back on hyper terminal. Both the hyper terminal baud rate and UART baud rate were set to the same values.
Correct text were printed back when we used a baud rate higher than 19200. However for any baud rate lesser than or equal to 19200 some of the characters from text file were getting skipped. The received text became severely garbled as we reduced the baud rate further.
The yellow waveform is what is received from PC (sampled at Rx pin of the board). The green waveform is what is sent back to PC from UART (sampled at Tx pin on the board).
Passing scenario:
Figure 7: Correct data at 38.4Kbps
If we see carefully the stop bit is a little wider than 1 bit width in the incoming stream.
Now we see the waveforms for 9600 bps
Failing scenario:
Figure 8: Missed data at 9.6Kbps
From the PC side the text file contained “This” which was correctly received as shown by the yellow wave-form. However, data sampled at Tx pin showed that character ‘h’ was skipped while the others (‘T’, ‘i’, ‘s’)were transmitted successfully.
In the application code, status bit were cleared on the bit-wise write basis which were inadvertently clearing other status bits as well. At high speed, by the time software was clearing the status bits data was already transmitted from the board so this issue was not observed but at lower speed, status bits were cleared before the data transmission and the issue was observed.
VII.C ONCLUSION &F UTURE W ORK
Above analysis and case-studies suggest that the error scenario and system level validation in addition to normal standalone LIN IP validation at silicon is of utmost importance and help us to produce bug free SOC. Though one cannot deny the fact that significant level of effort is needed to generate error scenario conditions and to capture system level design issues but this can significantly help the semiconductor industry in reducing cost by providing more healthy silicon.
Future recommendation is to validate the silicon at maximum temperature and at minimum voltage with slow matrix slot to catch the set-up/hold issues. Another recommendation is to run different LIN instances through different cores simultaneously to stress the system in a better way.
R EFERENCES
[1]LIN Specification Package – revision 2.1 –
[2]
[3]www.labvolt-taiwan/
[4]J. Fröberg, K. Sandström, and C. Norström, “LIN –protocol,
Development Tools and Software Interfaces for Local Interconnect Networks in Vehicles”, in Proc. of the 9th International Conference on Electronic Systems for Vehicles, pp. 1 –24, October 2000, Baden-Baden
[5]LIN Specification Package Revision 2.1, Nov. 24,2006
[6]LIN Specification Package Revision 2.0, Sep. 23,2003
[7]LIN Specification Package Revision 1.3, Dec. 12,2002
[8]www.ni/white-paper/9733/en/
[9] www.freescale/webapp/sps/site/overview.jsp?code=IFAT
OLIN&fsrch=1&sr=1&pageNum=1
[10]Jingcheng Wang, Xiaoming Wang, Xianglin Zhai, Hao Wang,
CAN/LIN Hybrid Network for Automobile, IEEE vesO5
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议