A novel approach to ensure complete coverage for validation of communication protocols by inducing jitter and glitches in clock and data

By Neha Singh, Amit Garg, Karthik Rao; Freescale Semiconductor India Pvt. Ltd.

The communication IPs (Intellectual Property) designed for and used across industry follow standard protocols. They need to interact with either data transmitters or receivers present on other SOCs (System-on-Chips) or with sensors that are commonly used industry wide. It thus becomes important to validate its functionality as well as electrical characteristics in accordance with industry standards. Also, it should be ensured that it is compatible with most of the sensors available in the market. One should keep in mind the effects of ageing such as jitter and glitches on the sensors. These loopholes if left unchecked can result in spurious data transfers and hence a failed communication. This paper talks about the various challenges in validation of communication protocols. It then proposes a novel approach to ensure complete coverage thus delivering a robust IP.

1- Introduction

The SOCs designed today include various communications IPs depending on the application requirement. These communications IPs play a key role in accessing data vital to the functionality of the SOC. The applications and IPs may vary depending on the area targeted by the SOC. For instance, IPs such as I2C, One-Wire, etc. are targeted towards Industrial and metering chips. The Automotive Chips require IPs such as Can, LIN, SENT, SPI, and UART to transmit or receive sensor data across various parts of the vehicle. It thus becomes important to ensure robustness of these IPs over various conditions of temperature, pressure, voltage etc. which ultimately lead to clock drifts, jitter and glitches in both data and clock.

2- Conventional methods of Validation for Communication IPs and their limitations.

The common methods used for validating different communication IPs on a SOC to cover maximum functionality are as follows:

2-1- Loopback between IPs on the same SOC

In this method, communication IPs such as SPI, UART, CAN, LIN etc. are validated by connecting two or more instances of identical IPs available on the SOC in loopback. This is done by configuring one of the IP’s as the transmitter and the other as a receiver and vice versa. It is one of the most widely used approaches nowadays as each SOC has two or more instances for most of the communication IPs. This approach greatly reduces the validation effort since separate setups are not required. Even in cases where only a single instance of the IP is available on the SOC, validation can be carried out by connecting them in loopback between two evaluation boards of same SOC.

Undoubtedly, it is an easy and a convenient approach but it has certain limitations attached to it.

Firstly, it may fail in finding issues due to the fact that both the IPs will have identical features and any anomaly in the behavior may be missed.

Secondly, since the driver and monitor are the same IP, it may be able to decode data generated by itself but may not be compliant with standard.

2-2- Using external devices or loopback between IPs on different SOCs.

In order to overcome the limitations of the previous methodology, these communication IPs are validated against standard transmitters and receivers. For instance, SPI Flash can be used to validate SPI; similarly I2C EEPROM can be used for I2C, the desktop hyper-terminal for the UART and Sensors used as transmitters for a SENT and other receiver IPs.

Another way could be to use the IP in loopback mode with a legacy SOC having an older version of the IP.

This again limits the validation in the following ways:

Firstly, external devices (memories, mouse, sensors etc) connected to the IP can only act as receivers or transmitters thus allowing the IP to be checked either as master or a slave.

Secondly, It is limited by the features supported by the external device used. The advanced features, if not supported on the legacy SOC will remain untested.

Hence this methodology does not suffice the validation requirements for achieving a complete coverage leading to a closure.

Figure 1: Loopback between Boards

2-3- Protocol Analyzers

Protocol analyzers capture and analyze signals as well as data traffic over a communication channel. Hardware or software, it is one of the most common tools used in validation of IPs based on a standard communication protocol. It gives a visual representation of the data transmitted as opposed to the logic analyzer or oscilloscope where each signal needs to be assigned and observed manually. One of the biggest advantages of using the protocol analyzer can be observed while debugging issues, if any on the IP as it flags anomalies present on the data, command, sequence of data etc. For instance in case of USB, the protocol analyzer decodes each transaction going between master and slave, and represents them in terms of packets and raises an alarm if any error occurs during the communication. Nowadays, these Protocol analyzers are available for I2C, SPI, CAN, USB and Ethernet etc.

Although, it may seem that using a protocol analyzer is the best possible solution looking at its advantages and ease of use, it does pose certain limitations that cannot be ignored.

Firstly, depending on the frequency at which it samples, it is possible for it to overlook the glitches occurring on the data signal.

Secondly, based on its availability they can be expensive and thus might not prove to be a cost effective solution.

Thirdly, in cases where there are features not supported by the analyzer it would lead to incomplete coverage.

The following graph shows the transaction of I2C protocol captured in an analyzer:

Figure 2: Protocol Analyzer showing I2C Transaction

3- Other limitations and challenges of the conventional methods used

In order to ensure complete functional coverage, one can use a combination of the above mentioned conventional approaches under normal conditions of temperature and pressure. Same goes for cases with IPs that have sensors providing them stimulus or input for validation to be carried out under normal conditions wherein coverage is complete. It is already known that the sensors are ideal and follow a standard protocol implying that they cannot generate any error in the data transmitted. This would lead to incomplete Validation coverage as the behavior of IPs during wrong data transfer will not be checked.

Also, these sensors have an aging effect which means using this for a long time can cause clock to drift or introduce glitch in data sent by these sensors. No doubt, each sensor comes with the data sheet which tells about behavior of these sensors at different conditions. But with these approaches, we have not covered the IP behavior with the change of sensor response, glitch in data, clock drift and noise.

4- Proposed approaches and their advantages

In order to overcome the issues faced or loopholes in the previous methodologies we propose some simple, comprehensive and cost effective Pattern based methodologies that can be used to achieve complete coverage ensuring a robust communication IP. By using these methodologies, any pattern of specified delay required by IPs under validation can be generated with the help of Timers or GPIO present within the same SOC or any other SOC as Timers/GPIO are mostly available in every SOC developed these days. This methodology not only helps in validating the functionality of communication protocols, but also helps in calculating the effect of jitter and glitches on IPs functionality. With availability of data on aging effect, it can also help in validating the life time of an IP.

The data pattern mimicking the protocol data can be generated using the following methods:

4-1- Generating patterns using Field programmable gate array (FPGA)

In this approach synthesizable Finite State Machines (FSMs) can be designed to generate the required pattern. The design can then be prototyped on a FPGA and the I/O from the FPGA pads can be connected to the SOC I/O. The design can be for either transmitter/receiver or both as per the requirement of the IP. This is analogous to drivers and monitors in the verification environment.

This has the following advantages:

It can generate any kind of error scenario if required.
It can also mimic the data pattern of various sensors.
Jitter and glitches can be inserted in order to check the robustness of the IP.

Pattern based methodology using FPGA is very easy and flexible approach by which any pattern compliant to standard IPs can be generated and modified depending on the requirement. The disadvantage for this approach is the cost incurred in procuring both hardware and software required for the FPGA setup.

4-2- Generating patterns using Timers or GPIOs present within a SOC

This approach requires the programming of Timers / GPIOs present on a SOC to generate the desired pattern. The programming is such that a high/low data pattern is generated on the I/O pins of the SOC with the desired voltage levels. This is then fed as stimulus to the IP under validation. This is a more cost effective solution since Timers and GPIOs are available in each SOC nowadays which can be used to generate the Standard IP patterns.

The major advantage of using these FPGA based or Timer based approaches is the introduction of jitters and glitches in transmitter or sensor which will help in mimic the behavior of sensor aging and help in validating the IPs response to these jitters and glitches.

5- Validation of SENT IP using Timer based Pattern Generation

To demonstrate the same, an experiment was carried out on an IP named SENT (Single Edge Nibble Transmitter) for inducing the jitter and glitches and validated the IP with the given specifications. For introducing jitter and glitches, generic Timer module present on an existing SOC was used to generate the same data pattern as required by SAEJ2716 protocol.

The Single Edge Nibble Transmission (SENT) Receiver module is a multichannel receiver for receiving serial data frames which are being transmitted by a sensor implementing the SENT encoding scheme and presents them to the CPU for further processing. This module is based on the SAE J2716 information report titled "SENT - Single Edge Nibble Transmission for Automotive Applications". As per this standard, the SENT protocol is intended for use in applications where high resolution sensor data needs to be communicated from a sensor to an Engine Control Unit (ECU).

The SENT encoding scheme is a unidirectional communications scheme from the sensor / transmitting device to the controller / receiving device which does not include a coordination signal from the controller/receiving device. The sensor signal is transmitted as a series of pulses with data encoded as falling to falling edge periods.

Following figure shows a typical block diagram of Transmitter and receiver communication used for SENT (Single Edge Nibble Transmitter) Protocol.

Figure 3 : SENT Transceiver–Receiver System

The data pattern generated using Timer IP for SENT Validation is shown below:

Figure 4 : SENT Protocol Waveform

As these sensors age through the course of their use they get more prone to inducing jitter, glitches and clock drifts which result in spurious data getting captured. SAE J2716 specifies an allowable range for the clock jitter and drift. The following graph shows the clock drift margin which can be tolerated by SENT Protocol.

Figure 5: Clock Drift Margin

Thus, these specifications must be met by the receiver to ensure its robustness. This can be achieved by inducing jitter or glitch in the data input.

Hence, by implementing this methodology, we can validate the effect of jitter and glitch on IP functionality. The figure below shows a data pattern with glitch and drift embedded in it. This was done at random for thousands of data samples.

Figure 6: Glitch and Drift in SENT Data

With this novel approach, we were able to confirm the SENT Specifications with respect to clock drift and jitter on Silicon.

This Technique is generic and can be applied to each communication protocol like CAN, I2C, LIN and so on.

6- Conclusion :

The methodologies proposed in this article for the validation of communication IPs to ensure their robustness and coverage are not followed conventionally. Using timers, GPIOs or eMIOS in order to generate data patterns and messages is unique and is not currently used for validation. Designing synthesizable data generators and receivers is also a novel approach. This approach to induce jitters, glitches and clock drifts is not a conventional practice. These methods are cost-effective and do not require any extra-hardware or set-up. They also reduce the cycle-time for validation of IPs, since small changes lead to a new version of the IP which can now be validated without the need to wait for procurement of protocol analyzers, sensors, etc.

7- Legend:

Acronym	Explanation
SOC	System on Chip
FPGA	Field Programmable Gate Array
GPIO	General Purpose Input Output
FSM	Finite State Machine
IP	Intellectual Property
SPI	Serial Peripheral Interface
SENT	Single Edge Nibble Transmitter
LIN	Local Interconnect Network
I2C	Inter Integrated Circuit
UART	Universal Asynchronous Receiver Transmitter
CAN	Controller Area Network